Debug information

[Andrew Haley]

Kelly O'Hair wrote:

> A few pieces of information... you probably already know most of this...
> 
>   * Debugging -g -O code has it's limitations, I assume that is
>     understood. Sometimes local variable information is not included,
>     sometimes the source line to instruction mapping is a bit hectic
>     or missing. It can be very valuable at times, just strange.

Sure.  As a matter of interest, we are trying to improve this in gcc.

>   * Using javac -g will just add information about local variables,
>     source line information is always there by default.
>     And you can't easily 'strip' debug information from class files that I
>     am aware of. I'm a bit puzzled how you can remove the debug
>     information from the classfiles and put that in a separate package.

We can't; I was only referring to ELF format files.  I'm not sure we'd
want to go to all the palaver to separate debug info from classfiles,
as it's not a huge difference in size.  (In contrast, the debuginfo in ELF
files can be huge.)

>   * It has been my experience that the resulting gcc object code (machine
>     instructions in the .text and data in the .data sections) from
>     building with and without -g can be different.
>     An a.out built with 'cc -g -O' and then stripped, is not the same
>     thing as an a.out built with just 'cc -O' in all cases.
>     Or at least that has been my experience.

If so that is a bug in gcc, which is not allowed to change its code
generation when debuginfo is enabled.  If you find any cases where this
happens I'll investigate.

>     If people are willing to accept any loss of optimization that
>     '-g -O' might cause, that is fine, just making the observation.
> 
>   * A "debug" build sometimes means that the native code includes
>     the assert() coding, valuable runtime checking, but potentially
>     a major performance problem and does increase the code size.
>     Did you mean to include assert() code? I assume not.
>     Our JDK "fastdebug" builds are built with -g -O and include the
>     assert checking code, so it's a bit of a compromise debug build
>     runs reasonably fast, can be debugged to some degree, asserts
>     can catch problems at runtime, etc.

> Having said those things, I have always been a supporter of the -g
> option just adding information to a .o or binary and not letting the
> desire to debug a program influence the optimizations you asked for.
> And an ability to just carry the debug information in a sidecar like
> package is a great concept.
> 
> So if you come up with some kind of setting for this, I would support
> adding it, just not sure you will get exactly what you want at first,
> may need to play with it.

I understand.  I'm quite happy to accept the fact that getting this
upstream into the real OpenJDK repository is going to take longer
than getting this into IcedTea.

Thanks,
Andrew.