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

[Dmitry Samersoff]

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.

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,
  *a1 + b1 + c3* have no sense etc.


-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


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.