JDK-8036003: Add variable not to separate debug information.

[Mike Duigou]

On Mar 1 2014, at 06:07 , Yasumasa Suenaga <yasu at 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