JDK-8036003: Add variable not to separate debug information. (original) (raw)

David Holmes david.holmes at oracle.com
Fri Mar 21 11:13:48 UTC 2014

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, SHFGNUCOMPRESSED [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/showbug.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

More information about the core-libs-dev mailing list