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.