Re: Should strip discard the .ctf section ?

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 7 Oct 2019, Rich Felker wrote:

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

Depends.  In other eco systems than embedded they use strip because of the 
DWARF size, not because of symbol tables (or, well, in reality they use it 
because their make systems use install -s, or somesuch :) ).

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

So, let them continue using sstrip then?

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

Don't compile with -gt then?

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

Ideally, yes.  Realistically, I think it's quite okay if the introspection 
capabilities enabled by -gt are relying on having file access and a 
section header, and hence don't need to have it in a loadable segment.

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

As soon as you make .ctf loadable, that's all necessary, indeed.


Ciao,
Michael.
P.S. hey, we could make the strip behaviour depend on the target: as soon 
as it's >= 31bit (ahem, s390) don't strip .ctf, otherwise strip. scnr  ;-)