Should strip discard the .ctf section ?

[Rich Felker]

On Mon, Oct 07, 2019 at 08:34:00PM +0100, Nick Alcock wrote:
> 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 think this should be possible, but I don't yet know how. I think
it's worth trying to find the way to do it.

>  - 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.

Users who want to strip binaries typically really want the tools to do
what they say. They also tend to use utilities like sstrip that
aggressively remove parts of the file that are not part of the ELF
load-time semantics. Requriring the strip utility to special-case .ctf
because you want it to be usable like a loadable section, but want to
avoid making it loadable because that's difficult to do in the
framework of BFD ld's implementation, is a bad hack.

>    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.

I think you're caught up in a gigantic desktop/server mindset. There
are plenty of systems where even a few hundred kB, much less a few MB,
is way too large to fit in storage for information that is not going
to be used. Introspectability is a niche feature. It's not part of the
C language. I was strongly against the choice to make .eh_frame
present by default even in non-debug-mode binaries when it was made,
and I'm likewise against imposing CTF on code that's not intending to
use it.

>    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.

Yes. The structure of the ELF file should reflect the semantics of
what's needed at runtime, so that the tooling can know what
transformations on the file are valid. (Moreover, there should be a
program header or some other way to locate the CTF at runtime via the
loaded content, if it's loaded, rather than having to go back to the
file on disk, which may no longer exist or which may not be
discoverable, e.g. with certain chroot/namespaced configurations,
etc.)

Rich