Re: [PATCH v3] strip: keep .ctf section in stripped file

["Guillermo E. Martinez" <guillermo.e.martinez@oracle.com>]

Hello Mark,

On Tue, Feb 28, 2023 at 03:27:13PM +0100, Mark Wielaard wrote:
> Hi Nick,
> 
> On Tue, 2023-02-28 at 12:59 +0000, Nick Clifton wrote:
> > > O, this surprises me. I wasn't aware binutils strip keeps unallocated
> > > sections by default. But apparently it does. It doesn't seem specific
> > > to ".ctf". Do you know why? This seems counter to how strip is supposed
> > > to behave, at least how I understand it.
> > 
> > Actually thinking about it, there are a few important un-allocated sections
> > that ought to be kept in a binary.  For example .gnu_debuglink and .shstrtab.
> > So maybe deleting unallocated sections by default is not such a good idea.
> 
> Sure, but both are those are actually added or rewritten during
> stripping.
> 
> There are some exceptions to the general rule in eu-strip of dropping
> not referenced, non-allocated, SHT_PROGBIT sections. SHT_NOTE sections
> are never removed (even if they aren't allocated), as are non-
> SHT_PROGBIT sections. ".gnu.warning." sections also aren't (even if
> they are non-allocated SHT_PROGBIT sections). And ".comment" sections
> aren't if not explicitly told to.
> 
> Guillermo's patch proposes to make ".ctf" another special case
> (defaulting to keeping).
> 
> I am mainly wondering why binutils strip already seems to keep ".ctf"
> sections (even without -g).
> 

I'm not plenty sure, but I can tell that it was done so, because CTF was
designed having in mind a lightweight debug format being shipped along with
the other allocated ELF sections:

	"CTF and DWARF data can coexist in the same ELF file, she said, since the
	CTF data has its own dedicated section. The CTF data is naturally
	smaller, but the format also includes compression to reduce the size
	requirements further. The result is that this data, unlike DWARF
	information, need not be stripped to get the executable file down to a
	reasonable size."

https://lwn.net/Articles/795384/

Kind regards,
guillermo