Page 2 of 3

Re: Who is responsible for Newlib/vbcc ?

Posted: Mon May 23, 2016 6:50 pm
by zzd10h
For my case, I still use gcc, no vbcc

Re: Who is responsible for Newlib/vbcc ?

Posted: Thu Jun 23, 2016 2:56 pm
by xenic
zzd10h wrote:For my case, I still use gcc, no vbcc
I should have directed my comment to phx since he was the one compiling with vbcc.

Re: Who is responsible for Newlib/vbcc ?

Posted: Thu Jun 23, 2016 4:53 pm
by blmara
xenic wrote:
zzd10h wrote:For my case, I still use gcc, no vbcc
I should have directed my comment to phx since he was the one compiling with vbcc.
Actually, I was the person compiling with VBCC and reported this elf message. Phx is the person updating the VBCC. If I understood correctly, Frank has located the problem to newlib (for example, launching AmiPDF generates this error message and also the message above indicates this is not a problem only for users of VBCC).

Marko

Re: Who is responsible for Newlib/vbcc ?

Posted: Fri Jun 24, 2016 5:43 pm
by xenic
blmara wrote:
xenic wrote:
zzd10h wrote:For my case, I still use gcc, no vbcc
I should have directed my comment to phx since he was the one compiling with vbcc.
Actually, I was the person compiling with VBCC and reported this elf message. Phx is the person updating the VBCC. If I understood correctly, Frank has located the problem to newlib (for example, launching AmiPDF generates this error message and also the message above indicates this is not a problem only for users of VBCC).

Marko
Pardon my confusion over who is who here. However, I tried running AmiPDF with Sashimi running and didn't see any messages. I even switched to the debug kernal, performed a cold reboot and still don't see any message in Sashimi when starting AmiPDF. Others have reported that they don't see the message either, so there must be something different about your system setup.

Re: Who is responsible for Newlib/vbcc ?

Posted: Sat Sep 17, 2016 1:54 pm
by salass00
The issue with the startup.o file used by vbcc has just been fixed in the latest newlib beta version with some help from Frank Wille (AKA phx) who is the maintainer of the AmigaOS vbcc ports.

As said before the issue wasn't harmful in any way and only showed itself when debuglevel was set higher than zero, which it really it shouldn't be for most people. The pretty much only reason to have a debug level higher than zero is if you are debugging the kernel or some other system component which is affected by this setting. If you are not using it to debug system components then you're just making the OS slower for no real reason.

Re: Who is responsible for Newlib/vbcc ?

Posted: Mon Sep 19, 2016 3:58 am
by ssolie
blmara wrote:Really, are there people developing newlib.library?
The AmigaOS development team looks after all the components as a collective. There are various members that specialize in pieces of the OS but everyone is welcome and able to work on any component. There is not one person who is the newlib maintainer.

In this case, vbcc is a 3rd party compiler and we do not test with it. If something happens to break with vbcc for some reason we will try to work it out but it is not the officially supported compiler. GCC is the officially supported compiler and we always test with that one.

Re: Who is responsible for Newlib/vbcc ?

Posted: Sat Sep 24, 2016 1:17 pm
by blmara
salass00 wrote:The issue with the startup.o file used by vbcc has just been fixed in the latest newlib beta version with some help from Frank Wille (AKA phx) who is the maintainer of the AmigaOS vbcc ports.

As said before the issue wasn't harmful in any way and only showed itself when debuglevel was set higher than zero, which it really it shouldn't be for most people. The pretty much only reason to have a debug level higher than zero is if you are debugging the kernel or some other system component which is affected by this setting. If you are not using it to debug system components then you're just making the OS slower for no real reason.
Great to hear both that the reason for this issues was found and it wasn't actually harmful. Thanks!

Marko

Re: Who is responsible for Newlib/vbcc ?

Posted: Sat Sep 24, 2016 1:17 pm
by Raziel
salass00 wrote:The issue with the startup.o file used by vbcc has just been fixed in the latest newlib beta version with some help from Frank Wille (AKA phx) who is the maintainer of the AmigaOS vbcc ports.

As said before the issue wasn't harmful in any way and only showed itself when debuglevel was set higher than zero, which it really it shouldn't be for most people. The pretty much only reason to have a debug level higher than zero is if you are debugging the kernel or some other system component which is affected by this setting. If you are not using it to debug system components then you're just making the OS slower for no real reason.
So, "SERIAL MUNGE DEBUGLEVEL=5" does not help debugging problems in programs but only helps debugging stuff in OS components and kernel?

Can i savely delete this parts then or should i keep MUNGE?

Re: Who is responsible for Newlib/vbcc ?

Posted: Sat Sep 24, 2016 1:20 pm
by blmara
ssolie wrote:...
In this case, vbcc is a 3rd party compiler and we do not test with it. If something happens to break with vbcc for some reason we will try to work it out but it is not the officially supported compiler. GCC is the officially supported compiler and we always test with that one.
Yes, I know and I am happy that you have helped to solve the issue even if the compiler is not the official one.

Marko

Re: Who is responsible for Newlib/vbcc ?

Posted: Sun Sep 25, 2016 4:43 am
by tonyw
"SERIAL MUNGE DEBUGLEVEL=5" does not help debugging problems in programs but only helps debugging stuff in OS components and kernel?
Certainly not! Using the "debug" kernel is essential if you are doing any sort of program debugging - OS components or otherwise.

"Serial" means print debug information such as output from the IExec->DebugPrintF() function directly to the serial port. If you are debugging a system component you need to do this because if there is a crash, it will help get all the information printed. Using printf() or a debugger likely will prevent the last line or two from appearing.

"Munge" is not essential but does make it more likely that a program that forgets to initialise its memory will fail.

"DebugLevel=5" is rather extreme and won't help you debug anything except the inner-most parts of the OS. Leave it at "1" to get the minimum debug output from the kernel, I/O drivers and DOS.

So if you are debugging software (any software), make sure you use the debug kernel and "Serial Munge DebugLevel=1". If you are not debugging or testing anything, use the normal kernel and debug level "0".