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

[Daniel D. Daugherty]

On 3/18/14 12:22 PM, Andrew Hughes wrote:
> ----- 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).

Very cool. Thanks for the clarification.

Dan


>
>> 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.
>>