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

[Andrew Hughes]

----- Original Message -----
> On 3/17/14 7:19 PM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> On 3/3/14 2:49 PM, Omair Majid wrote:
> >>> * David Holmes <david.holmes at oracle.com> [2014-02-28 18:48]:
> >>>> There are three pieces to all of this:
> >>>>
> >>>> 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.
> >>> Any chance we could clean up the names too? It's not obvious to me why
> >>> FDS means 'generating debuginfo files'.
> >> FDS stands for Full Debug Symbols and is defined that way in
> >> quite a few Makefiles... We just call it FDS for short...
> >>
> > At least to me, Full Debug Symbols suggests #1 (i.e. that symbols are
> > generated
> > in the binaries), not #2. That's why it sounded so odd to me when you
> > suggested
> > turning it off, when we discussed this before.
> >
> > It's also not clear why you'd want a situation where #3 would be turned
> > off, but
> > not #2, as you end up with two copies of the debug symbols. That's the
> > problem
> > I believe we have with our builds; we can turn the stripping off, but then
> > we
> > end up with duplicate debug information.
> >
> > Do we need more than just the following three alternatives?
> >
> > #1. No debugging information at all.
> > #2. Debugging information left in the original binaries.
> > #3. Debugging information stripped from the binaries and zipped in separate
> > files.
> 
> The way Oracle does it is complete debug info in the
> separate files and partial debug info left in the original
> binaries so you get symbol names in stack traces for those
> cases where the full debug info bundles are not available.
> 
> I'm not clear whether we need a 4th alternative or if #3
> covers this case.
> 

The intent was for #3 to cover this case (i.e. whatever Oracle does now)
and for #2 to be what the GNU/Linux distributions want (i.e. binaries with
all debuginfo generated and left intact so they can do their own stripping).

> Dan
> 
> 
> >
> > It sounds to me like Oracle want #3, while distros want #2 and I imagine
> > some
> > end users may just want #1 for a faster, smaller build.
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07