David, My point was that we don't need in fine grained selection of elf sections on strip - three options are enough.
> 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) Sorry! it should be: full strip + copy-none + zip -Dmitry On 2014-03-21 15:13, David Holmes wrote: > 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 th > *Subject:* Fwd: Re: Compute sizes of classes loat 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.
