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

[Daniel D. Daugherty]

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.

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.