Debug information

Kelly O'Hair Kelly.Ohair at Sun.COM
Tue Mar 17 21:44:31 UTC 2009


Andrew,

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.

   * 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.

   * 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 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.

-kto

Andrew Haley wrote:
> In GNU/Linux/BSD/etc systems we normally want to be able to debug
> installed packages.  So, in many distributions there is a rule that
> all packages must be built with full debug information.  This isn't
> quite as bloated as it might sound, as we extract all such debug
> information files and put it into separate debug packages.  So, when
> someone has a problem that we need to debug we can download the debug
> package to their computer and attach a debugger without needing to
> recompile anything.
> 
> As far as I've been able to determine there is no simple way to turn
> on debug information in OpenJDK builds.  So, in IcedTea we have a
> number of patches that turn on debugging in various makefiles and
> build.xml files, but of course we miss things.  I recently tried to
> debug javac but discovered that it wasn't possible because it hadn't
> been compiled with full debug info:
> 
>         <javac srcdir="${src.classes}" destdir="${build.bootclasses}"
>             source="${compiler.source.level}"  debug="true" debuglevel="source,lines"
> 
> Note that there's no way to override the debuglevel without editing
> build.xml.
> 
> I think we need a single overriding option when building OpenJDK that
> enables debug information everywhere, no matter what the build target.
> Note that I'm not talking here about any of OpenJDK's internal
> debugging aids, just the -g options passed to javac and the various C
> and C++ compilers.
> 
> While I could write this as an IcedTea patch, I believe that it's
> something that should go into OpenJDK proper.  Would that be
> acceptable?
> 
> Thanks,
> Andrew.
> 



More information about the build-dev mailing list