Should strip discard the .ctf section ?

Nick Alcock nick.alcock@oracle.com
Mon Oct 7 19:34:00 GMT 2019


On 7 Oct 2019, Nick Alcock spake thusly:

> I have had people asking me to make .ctf a loaded segment, but in
> addition to having the same qualms as you about loading this section in
> and eating memory before it is in widespread use, I can see no way to do
> such a thing without a radical linker rearchitecture.

To reiterate:

 - I am happy to make the CTF section loaded *if* someone can show me a
   way to make this be the case without changing its format in ways that
   impair its compactness and without having to rewrite basically the
   entire linker in the process. In particular, it should still be able
   to elide strings from the CTF-internal string table that are also
   present in the ELF strtab, and it should still be able to have the
   CTF-internal object and function info sections ordered such that they
   are in the same order as the symbols in the ELF symtab (not yet
   implemented in libctf, but implemented in GCC and wil be added to the
   libctf side with no further ld/bfd changes needed).

   I have no *fundamental* objection to making the CTF section loaded in
   the future, though libctf is unlikely ever to use the loaded content:
   however, other libraries might in theory use it in future, and I
   don't see any reason not to let them. My only objection is that doing
   this requires massive linker changes. I'd be quite happy to
   transition to a loaded section in future, as long as libctf isn't
   required to use it and can still load it using BFD as it currently
   does (requiring the use of the loaded sectiosn would probably require
   very painful API changes and horrible changes to libctf users).

   I didn't do this because even trying to analyze whether it might be
   possible got me tangled up in a massive pile of dependent things that
   must be done first, most of which seemed to involve even more massive
   lists of changes and honestly this seemed like way too much work for
   what is after all fairly redundant (since everything works fine
   whether the section is loaded or not, and making it work while
   non-loaded was only moderately painful). Plus it just seemed like the
   sort of huge invasive change for marginal benefit that would be sure
   to be rejected. But if there is a way to do it *without* a huge
   invasive change, I'd be happy to (though obviously I want to keep
   doing the linking *in the linker* rather than resorting to horrible
   kludges like post facto invocation of objcopy behind the scenes or
   something like that). But maybe it could be done anyway. Maybe the
   strtab/symtab layout could be moved much earlier, or address
   assignment could continue past the point at which the strtab/symtab
   are emitted? (We'd have to compress the CTF section before that
   point, too, obviously).

   Now I'm wondering if one could handle this general problem by making
   ld repeatedly invoke the whole bfd linker machinery, linking first
   loaded sections that don't depend on anything, then sections that
   depend on those, etc, until all are done, with a final pass to link
   the non-loaded sections in. This not be remotely possible though: I'm
   not sure if you can invoke the BFD linker machinery repeatedly like
   that).

 - On the contrary, making the CTF section stripped by default appears
   to render it useless for most of its intended use cases: the whole
   point of it is that it is so tiny that it doesn't need to be stripped
   out. I *am* philosophically against this one.

   The only argument people have given for stripping it out is not that
   it's consuming too much space but that all sections of some type X
   must be stripped out no matter what. I'd tend to consider the purpose
   of strip(1) to be to save space, so arguments about what sections
   should be stripped that do not come down to "this section is too big
   and nothing uses it" are not arguments I find terribly convincing,
   particularly not when the whole reason for CTF's existence is to try
   to make something small enough that it can be used for type
   introspection without being so big that people are tempted to strip
   it out anyway.

   It seems likely that making the section loaded might stop people
   suggesting that it should be stripped out, by emphasising that "hey,
   this is really used". This seems like a bad reason to make that
   change, to me, but hey, I guess it *is* another reason. My only
   problem with making the thing loaded is practical (I have no idea how
   to do it). So, if anyone does have any idea, please do say.



More information about the Binutils mailing list