HI Mike, > - I would expect that the flow is something like an extended version of > https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : > 1. Compile source files with some form of "-g" > 2. Create separate debug files for object files. > 3. Strip object files. > 4. Add gnu_debuglink to object files. > 5. Link library or executable which should carry along links to debuginfo. > 6a. Debugging, testing, profiling, etc. by developers. > 6b. Packaging for program bits and debuginfo. > 7. Testing and Use.
rpmbuild will execute 2 to 4 implicitly, Modern ELF binary has .note.gnu.build-id section. Debugging tools (e.g. GDB and SA in JDK) use this section for finding debuginfo files. If OpenJDK8 which is shipped by RPM is crashed and we want to analyze core image, we have to merge debuginfo and executable at first (e.g. eu-unstrip command). GDB and SA can find valid debuginfo through .note.gnu.debug-id or .gnu_debuglink section. But these tools can find /usr/lib/debug/<path to executables>/<executable name>.debug . They are cannot find *.debuginfo which are made by makefiles in OpenJDK tree. Yasumasa On 2014/03/02 8:08, Mike Duigou wrote: > > On Mar 1 2014, at 06:07 , Yasumasa Suenaga<y...@ysfactory.dip.jp> wrote: > >> Hi David, >> >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) >>> >>> It may be that we don't have clean separation between them, and if so >>> that should be fixed, but I don't see the current proposal as the way >>> forward. >> >> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not >> generated. >> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. > > I think David's list (kudos) is very helpful as I haven't seen the > requirements articulated this clearly anywhere else. > > Some comments: > > - Are there important tools that cannot deal with external debuginfo files? > If we can put debuginfo into external files why would we ever want unstripped > binaries? Is strip policy really necessary? Strip policy would seem to only > be necessary if there are tools which can't handle external debuginfo. > Assuming that everything can use external debuginfo then the policy would be > to strip everything. > > Do I understand correctly that rpmbuild can only deal with unstripped > binaries and generates the stripped rpm package and debuginfo package. It > sounds kind of strange that find-debuginfo.sh wouldn't be able to use already > generated debuginfo files. > > - I would expect that the flow is something like an extended version of > https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : > 1. Compile source files with some form of "-g" > 2. Create separate debug files for object files. > 3. Strip object files. > 4. Add gnu_debuglink to object files. > 5. Link library or executable which should carry along links to debuginfo. > 6a. Debugging, testing, profiling, etc. by developers. > 6b. Packaging for program bits and debuginfo. > 7. Testing and Use. > > Hopefully I didn't get any of those steps in the wrong order. What are the > "you-cant-get-there-from-here" gaps and breakdowns from implementing this > process? > > - Whether for the FDS debug symbols or RPM debuginfo packaging it seems that > the default debug level isn't quite right. I believe that in both cases > what's wanted is abbreviated debug info, mostly function names and line > number tables, for building stack traces. This is not the debug info that is > currently generated. > > There are four basic alternatives for levels of debug info: > 1. (-g0) No debug info whatsoever. > Only exported functions and globals will have names. > 2. (-g1) Abbreviated debug info. > All functions have names and line number information. This seems to be > what is needed by both FDS and RPM debuginfo files to produce nice stack > traces. > 3. (-g) Default debugging info. > Adds macro expansions and local variable names. Suitable for source level > debugging. > 4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info. > Most suitable for source level debugging including debugging of optimized > code. It is not clear that anyone would want to build the entire product with > this option. > > Compilations are currently done with a mix of -g, -g1, and -gstabs. It would > be good to rationalize this somewhat and provide a mechanism for developers > to tweak generated debugging output for files or components. > > - Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some > platforms? > >> So I change: >> >> 1. Separating to add "-g" option to compiler from executing objcopy. >> 2. jdk/make/Images.gmk regards STRIP_POLICY. >> >> >> As I mentioned earlier, this issue is related to RPM. >> So I hope to fix it before JDK8 GA is released. > > This won't happen (at least not for Java 8u0). Java 8 is already late in it's > final candidate stage. It is too late for the initial Java 8 release to > consider this magnitude of change. In any event, since the Java 8 rampdown > began back in November, any change would first have to be applied to Java 9 > and then approved for backport to a Java 8 or an update release (and it is > also possibly too late for 8u20). > > Inability to include your suggested change in Java 8 or 8u20 is in no way a > rejection of the ideas or contribution, it's merely a normal consequence of > timelines and process. > > Mike
