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.
