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

[David Holmes]

On 21/03/2014 7:36 PM, Dmitry Samersoff wrote:
> David,
>
> In practice, we don't have to much to keep internally.
>
> There are no reason to copy out some of .debug_* sections but keep other
> ones.

I'm not familiar with exactly what the different strip options do but 
the point is this is covered by the strip-policy.

> So we have a matrix:
>
> (a) Strip mode:
>
> 1. full
> 2. keep symbols
> 3. keep symbols and .debug_*
>
>
> (b) Copy mode:
>
> 1. Copy all to ext file
> 2. Copy none to ext file
>
>
> (c) Compression mode:
>
> 1. none
> 2. per-section compression, SHF_GNU_COMPRESSED [1]
> 3. zip entire file
>
> Where
>    *a2 + b2 + c2* have perfect sense,

So now your compression mode may apply to either the external file or 
the original? That's even more permutations.

>    *a1 + b1 + c3* have no sense etc.

Why does full strip + copy-all + zip make no sense? It is exactly what 
we do with embedded builds. (Naturally you have to copy before you strip)

David
-----

>
> -Dmitry
>
>
> Refs:
> 1.
> https://sourceware.org/bugzilla/show_bug.cgi?id=11819
> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01780.html
>
>
> -Dmitry
>
> On 2014-03-21 12:57, David Holmes wrote:
>> On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote:
>>>
>>>> I don't think this quite works as there are other variations not
>>>> captured here. Rather than "zipped" it should just be "external".
>>>> Whether the debuginfo files are zipped or not is then an additional
>>>> build time option. Additionally we still have to be able to control
>>>> the degree of stripping that is carried out. It doesn't make sense to
>>>> me to try and enumerate all possible combinations as top-level
>>>> configure options.
>>>>
>>>> Further, as Dan was saying, this doesn't capture the overlap between
>>>> "internal" and "external" because we still leave some symbols internal
>>>> even when creating the debuginfo file.
>>>>
>>>> So I don't think this proposed categorization works. We still have
>>>> three aspects:
>>>> - generating symbols into the object files
>>>> - stripping symbols from the final binaries
>>>> - saving symbols into an external form
>>>>
>>>> Each of which can potentally be varied (of course if you don't
>>>> generate symbols in the obj files stripping and saving are non issues).
>>>
>>> But they are not independent on each other!
>>>
>>> Unless you generate debug symbols, you can't strip them, nor save them
>>> elsewhere. So generating debug symbols (your item #1) is a prerequisite
>>> for the rest of your items.
>>
>> Yes I just said that. :)
>>
>>> And while, technically, you can save symbols externally, and at the same
>>> time keep them in the binary, that does not make sense. So, in a
>>> practical sense, you are going to do #2 if you are going to do #3.
>>
>> But you can vary what is kept internally independent of what is made
>> external.
>>
>>> And you can't zip external symbols unless you create a non-zipped
>>> version. And if you zip them, it does not make sense to keep the
>>> non-zipped version.
>>
>> zip vs non-zip is just an issue of disk space. It is not a fundamental
>> configuration choice, just a variation on how external symbols are
>> packaged.
>>
>>> And yes, we do not strip all debug information when creating external
>>> debug info. But there seems to be no real use case (not even for
>>> IcedTea, as it turned out) to want a completely stripped binary, I don't
>>> think that's worth discussing much. That's just part of how the external
>>> debuginfo scheme works.
>>
>> Umm we fully strip all our binaries in embedded.
>>
>>> Can you give a more concrete example of the variations of your "aspects"
>>> that you think my suggested solution would not capture?
>>
>> I think I already have. There aren't tree simple choices here, there are
>> three aspects, each of which could have different variants.
>>
>> If I could draw a flow chart easily I would but basically if you
>> generate debug symbols you can then select what symbols are kept
>> internally (the strip policy) and what are put externally (objcopy
>> options), then for the external symbol file you can choose zipped or
>> unzipped.
>>
>> Multiple inter-connected choices, not just three (or four if you add
>> zipped)
>>
>> David
>>
>>> /Magnus
>
>