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