Re: Should strip discard the .ctf section ?

[Orlando Arias <orlandoarias at gmail dot com>]

Greetings,

Outsider here who has been following this discussion for a while now.

On 10/7/19 2:52 PM, Nick Alcock wrote:
> Maybe, but I'm... not aware that there is actually a problem that needs
> a new flag to solve it here. There is a default that you dislike, but I
> don't actually know why you dislike it: if it leads to worse behaviour
> for end-users I'm not aware of it. That users get to keep .ctf sections
> once they explicitly ask for them to be generated seems like a *benefit*
> to me.

The problem is that you are arguing for a default that goes against the
behavior of the tool. When I run strip, I expect all symbols from the
object file to be discarded. 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.

>>> If we *do* strip out CTF by default, no-one will ever use it, because
>>> packaging systems will routinely strip it out into the debuginfo
>>> packages so it is never there. I've seen how hard it is to avoid
>>> stripping this sort of thing out when packaging if strip does it by
>>> default: when I was putting .ctf sections into kernel modules, I had to
>>> *patch parts of RPM at runtime* to do it, and I had to do this on a
>>> package-by-package basis. This is not something any sane person is ever
>>> going to do, so in practice if strip(1) strips out .ctf, nobody who
>>> wants their program to work when packaged by any major distro is ever
>>> going to be able to use it, unless they're writing a debugger.
>>
>> If .ctf does not have the SHF_ALLOC flag, like DWARF .debug_*, I think
>> the right behavior here is to add --keep-section=.ctf to the packaging
>> systems where strip/strip -s is used. This does not require fixing more
>> packages, because you already have to add -gt to CFLAGS.
> 
> Most packaging systems do not make it easy to pass arbitrary flags to
> strip(1).
> 
> The most practical way I've found to do this in RPM involves patching
> RPM at runtime (you have to dig up parts of the shell scripts RPM
> invokes from /usr/lib/rpm, copy them into the build tree, patch them,
> and hack the internal macros that invoke the script out of /usr/lib/rpm
> so that they use your patched copy instead -- and the necessary patch is
> RPM-version-dependent, as are the names of the macros you have to
> replace).
> 
> You'll pardon me if I don't want to inflict *that* on end-users.
> 
>> Then, I don't think stripping .ctf by default will increase the
>> deployment cost.
> 
> I have practical experience of this, and the scars. It does. :(
> 

It sounds to me like you should be taking this up with the RPM
maintainers. You are attempting to change the way a tool outside the
build system works because your build system is not flexible. Arch
Linux's build system has this covered already: in your PKGBUILD script,
add '!strip' to options, then in the package() function, run the strip
command as you wish. Yes, I have used RPM before, there is a reason as
to why I do not use it anymore [there are many, but I digress].

Furthermore, it looks to me you are attempting to stir up adoption by
forcing the format to be included in files by changing the behavior of
the tools, not by any merits the format may actually have. To me, this
is uncouth, to say the least.

> I'm trying to steer a middle road here.
> 
> On one side you can treat this just like debuginfo, and then it ends up
> useless in the debuginfo packages and you can't actually use it unless
> you jump through fairly horrifying hoops to get the right flags passed
> to strip(1), even though you *already said* you wanted CTF when you
> passed -gt to the compiler.

Except that when you pass the gcc front-end something on the lines of
-ggdb, strip will still kill the debug section. I do not see why .ctf
should be treated differently.

For what is worth, in my use case, having debug symbols and other types
of informations in binaries is pointless. My debug sessions for example
revolve around placing binaries in small, embedded platforms. Some of
them are freestanding environments, some of them are hosted, some of
them are semi-hosted [during testing]. The way I work with these
platforms is by setting up some form of gdbserver and run the binary
through it, be it as part of a JTAG debug software, or an actual
gdbserver binary running on a hosted system. In either case, I keep
symbol data in a separate file. Why? Because the freestanding and
semi-hosting environments do not care about them and they are not
loaded, and the gdbserver process does not care about them. The only
thing that actually cares about these symbols is the gdb process itself,
which is not running on the target platform.

This brings me to my next point: flagging .ctf as a loadable section is
a horrible idea for these platforms. I do not need larger binaries to be
loaded. I already need to wrestle my code to use as little resources as
possible, I do not need a new loadable section to consume even more
resources.

Also, I believe that there has been some confusion in the discussion:
when Rich Felker mentioned ``Program behavior absolutely should not
depend, ever, on details of the file outside of the loadable segments.''
I believe he is referring to you executing a particular binary, and the
resulting process attempting to use the non-loadable sections of its own
ELF file. Of course, a special consideration is to be made about the
process being a debugger debugging itself, but even in that case, the
debugger examines the ELF file that created the process and extracts any
relevant information from there. It does not obtain debug/symbol
information from the memory image/virtual address space of the debugged
process.

Again, this is an outsider's view. Take it as you will.

Cheers,
Orlando.