ld CTF deduplicator should be coming fairly soon (was Re: genscripts comment tidy)

[Fangrui Song]

On Sun, May 31, 2020 at 5:42 AM Nick Alcock via Binutils
<binutils@sourceware.org> wrote:
>
> On 16 Oct 2019, Nick Alcock spake thusly:
> > On 16 Oct 2019, Nick Clifton spake thusly:
> > > No. :-(  But it would be nice to have.  Fancy writing a node in
> > > the ld.texi file ?
> > Maybe in a week or two. I really really want to get a working CTF
> > deduplicator posted here first. :)
>
> Oh ha ha ha, hark at my foolish optimism. After literally months of
> going up various blind alleys I have this working at long last and am
> getting it into shape for posting in the next week or two (as multiple
> series, preparatory stuff and bugfixes in existing code first,
> deduplicator second, with a bunch of ld performance and resulting-
> CTF-size figures in the cover letter for the second series).
>
> Minimal impact outside libctf/ (a couple of new command-line options to
> enable different varieties of type deduplication that authors of very
> large codebases might like: would -z be a suitable place in the option
> space for that? Perhaps -z ctf-*? I've never been entirely on what -z
> stands for...)

I guess this is just due to how GNU ld handles command line options.
lexsup.c handles common options for all binary formats.
emultemp/elf.em handles ELF specific -z options.

> Going silent like this is bad of me, sorry. I'll try not to do it again:
> with ld dedup in, libctf approaches usability (with only one more libctf
> feature needed before GDB can map from symbols to types without DWARF)
> and it becomes more important that I pay attention!
>
> Catching up with massive binutils list backlog first, but if it turns
> out nobody's documented the genscripts stuff in the meantime, I might
> get to writing that genscripts texinfo node :)

One (strong) objection remains:) I think strip/objcopy should drop
.ctf by default.
This is always how the tools work and I don't think .ctf should break it.
(And I don't think breaking the rule can give .ctf a significant market share -
which is the whole purpose behind the intention to break the rule).
Distribution package managers which want to adopt .ctf should opt-in,
rather than opt-out.
Many pieces of software do strip in their build systems. They do want
to drop extra sections
added by distribution CFLAGS/CXXFLAGS. For some software (e.g.
seabios), not able to dropping unneeded sections can lead to failures.