This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should strip discard the .ctf section ?


Greetings,

On 10/7/19 4:01 PM, Michael Matz wrote:
> But strip doesn't only "remove symbols".  It removes an effectively 
> arbitrary set of sections and meta information of files, and that set 
> historically happens to be "somewhat-related-to-debug-thingies", with one 
> invariant being that after stripping a final executable it still must run 
> as before stripping (1).  Stripping relocatable files already breaks this 
> (and that noone is surprised by this is merely experience and historic 
> behaviour; a complete newcomer might say that's a bug in strip, because 
> "it should only remove debug stuff, not symbols", and that would be 
> reasonable)
> 
> [(1) and there are even GNU libraries that actually do break by stripping 
> them, e.g. glibcs libpthread/libthread_db in the past, when it played 
> games with existence of .symtab entries.]

Yes, I am aware of this behavior, and I am well aware of the kinds of
breakage that can happen. My point remains though, it's something I
would not expect to remain with default options.

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

> 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.
> 
> Then use strip -s (aka --strip-all).

So you are now forcing me to change my workflow because of what would be
convenient to you. And well, you can make the argument that I expect a
different type of behavior out of a tool because it is
convenient/historical to me. I accept that. However, I will raise my
package manager point again. I noted you have a @suse.de e-mail address.
I do not mean to sound demeaning/condescending in any way or form, but
again, it looks to me like inflexibilities in the way RPM operates may
be swaying your choices. If your packaging tools do not let you choose
how you build things, you should probably look at making it more
flexible, an action that directly affects you, rather than changing how
external tools work, an action that affects everybody.

Cheers,
Orlando.

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]