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
