aph at redhat.com
Wed Mar 18 10:50:15 UTC 2009
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.
More information about the build-dev