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

[David Holmes]

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