Re: Should strip discard the .ctf section ?

[Nick Alcock <nick dot alcock at oracle dot com>]

On 7 Oct 2019, Orlando Arias told this:

> On 10/7/19 4:01 PM, Michael Matz wrote:
>> And let's be honest, there are only two reasons why something like strip 
>> exists at all: (a) hiding of internal information from 3rd parties, 
>> whatever we think the effectiveness of that is, and (b) to remove stuff 
>> that's mind-boggingly large for it's usefulness (hello stabs and DWARF).
>
> The second point is what is important to me. I do not care how small the
> .ctf section is, it is pointless to have in my targets. I do not need
> that information there.

You realise that we're not talking about adding this stuff when you
compile with -O2 -g0, right? You have to *explicitly pass an extra
compiler flag*, -gt.

In practice, while I'm going to be compiling whole distros with this
flag as a test case, I don't expect it to be used wholesale routinely
until it's got wider adoption: there's no point building it in if you're
not going to use it! I'm not interested in jamming it down people's
throats: I'm interested in people who need type information in C
programs (possibly others, possibly including GDB; possibly their own in
different translation units or shared objects) being able to get it,
while right now they can't (the best they can do is include relevant
headers and hope they're compatible and capture the types they need, and
hope they can get them all at compile time).


(This is not even the first section strip treats like this:
-frecord-gcc-switches emits the GCC compiler flags into a non-loaded
section that is not stripped by strip by default: as with CTF, it's not
there unless you ask for it by providing the compiler flag. So
loadability is clearly not exactly the same as nonstrippability. The
rationale here is the same: if you stripped out .GCC.command.line into
the debuginfo, it would be pretty useless because it would never be
there when you needed it. Of course, this section is much smaller: I
don't imagine CTF will be only 1K long for most binaries, though after
dedup it might get quite close: I've seen CTF sections on the order of
8--10K for things like bash and ls before.)

>> With my distro hat on: if I could get the biggest usefulness of DWARF for 
>> shipped binaries (namely halfway sensible backtraces and typeinfo for the 
>> arguments, so that crash debugging by hand at remote sites doesn't turn 
>> your brain into a complete sponge) for, say, 10% of .text, then _of 
>> course_ I want to have that shipped with the binaries.
>
> For this matter, as far as I am aware, you can still get your core dump
> and examine it. Your symbols do not need to be on the remote server.
>
>> So, yeah, don't strip .ctf by default.  Though, of course, again with my 
>> distro hat: I could cope with default stripping, I'd simply patch our 
>> binutils to not strip :)
>> 
>>> I do not wish having to pass an extra 
>>> --remove-section=.cft because the behavior of strip suddenly changed to 
>>> something that is removed from the norm.

Point of order: CTF does not contain symbols of any kind (that would be
a waste of space: when it needs to cite a symbol, it refers to the ELF
symbol table). It contains type introspection information, and things
other than debuggers may very well use it (though I do expect debuggers
to be a major use case).

In any reasonable use case in which you had built in CTF, you wouldn't
pass strip --remove-section=.ctf because that would break either the
binary itself or whatever other binary using libctf you were expecting
to use its CTF info.

(Why would you build in CTF info in the first place if you only wanted
to throw it away? People keep on citing this and I have no idea why.
Maybe they think it gets built in with the default configure -g -O2
flags? It doesn't.)

> again, it looks to me like inflexibilities in the way RPM operates may
> be swaying your choices.

I will admit that the knowledge that at least one package manager exists
that does not let you modify strip arguments *is* influential. That it
is a major one is significant, too.

FYI, as far as I know dh_strip *also* does not support passing arbitrary
flags to strip...