Re: Should strip discard the .ctf section ?

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

(Hah! Thank you for spotting a horrible mistake on my part: see below.
Fix forthcoming.)

On 8 Oct 2019, Fangrui Song said:
> On 2019-10-07, Nick Alcock wrote:
>>I nearly broke my brain trying to do so. I'd be immensely happy for
>>someone else to look :)
>
> Whether .ctf has the SHF_ALLOC flag or not should not cause a drastic
> change in the linker design.

I've already explained why: bfd_elf_final_link currently insists that
addresses of loaded sections must be laid out before the symtab or
strtab are laid out, so at the very least their size must be known --
but CTF sections depend on the content of both, and are often
compressed, so their size depends on their content.

There are almost certainly a lot of assumptions scattered through
elflink.c regarding this state of affairs. Fixing them would be nice (I
have other people internally saying that it would be nice if this
restriction were lifted, and it would uncrustify some other bits of
elflink.c and related code as well)... but it's not a small change and I
think it's asking a lot to have this huge thing done before CTF sections
could be added.

As I said, I have no fundamental objections to doing that -- it's just a
tangle of hissing snakes I'd rather deal with once I've got CTF closer
to feature-completeness, since I suspect it'll take longer to get right
than everything else put together.

>                               It seems .ctf has the dedup feature so
> "Rules for Linking Unrecognized Sections" (which simply combines input
> sections) does not apply.

Well yes, that's why we need explicit linker support in the first place :)

> If .ctf has the SHF_ALLOC flag, and its size can vary with the addresses
> of other sections. Then, computing its content should be an iterative
> process. You may need to check lang_size_sections and the like.
> The iterative framework is already there -

Is it? I looked for it and couldn't find it. Some pointers would be much
appreciated...

> .ctf should be considered a debug section.

How many times do I have to say that it isn't? Type introspection is not
exclusively a debugging facility! -fno-rtti is not a debugging option!

>                                             gcc -gt generates it. -g
> options are used to customize debug info generation.

There was quite a lot of internal debate about the right name for this
option. There are arguments against basically everything. I for one am
amenable to changing it, though no doubt this would ignite more
argument...

> --strip-all removes .symtab and .strtab. If .ctf references .symtab but
> is not stripped along with .symtab and .strtab, the resulting .ctf will
> just be broken.

... good point! This is clearly a horrible mistake on my part. Phew,
thank goodness you spotted this one early.

The gain here is mostly from sharing symbol name strings, so I think we
should be sharing with .dynstr, since that's where the symtab strings
are kept and frankly it's the only symtab with significant amounts of
useful content in a stripped executable. Illumos uses the concatenation
of .dynstr and .SUNW_ldynsym, the latter being an executable-only string
table used to allow symtab lookups to work on stripped executables. We
don't have .ldynsym (not yet, anyway) so sharing with .dynstr alone is
clearly right.

(It would be nice if we could share with both that *and* .strtab, but
since .strtab is hardly ever there I don't think this is likely to be
worth doing. We could share with .strtab in statically-linked
executables only but I don't think they're common enough to be worth
special-casing.)


I'll submit a patch fixing the linker and libctf to use the right
section.

>>I have several machines with much less space than that. My firewall has
>>512MiB of flash, total... and yes I want it to have CTF everywhere so I
>>have a good reason to keep it small!
>
> As Rich said, when people run strip, they really want to get rid of
> these sections (outside of loadable segments) that cannot affect program
> behaviors.
>
> At least 3 people on this thread have explicitly opposed to make .ctf
> survide under strip. This is a pretty strong signal that many people
> are against you changing the behavior.

They all seem to be operating under the assumption that -gt will be on
by default, though. Since it's not, you won't find CTF sections
appearing unless you explicitly ask for them. If you explicitly ask for
them, why would you want them stripped straight back out again? This
seems like a terrible user experience.

(I've also said exactly this in the email you responded to, in a section
you quoted but didn't reply to.)