ld: compressed sections that depend on the symtab and strtab contents (linker people, am I crazy?)

[Nick Alcock]

On 8 Aug 2019, Nick Alcock said:
> But I don't think this is necessary! I know I've been silent for ages,
> but this is *not* because I've been wrestling with ld: I fixed the
> breaks-the-assembler problem the day after I reported it. I'm using it
> for real before I try to post again (work deadline), with very large
> links and custom third-party users of libctf's linking machinery to make
> sure I've got the API right, and am pruning a lot of bugs out of the
> libctf portion and lifting a lot of long-standing restrictions.

This is basically done now (followed by a couple of weeks of letting it
bake locally while I was on holiday), but there were lots of bugs, so
the patch series is a fairly numbing 33 patches long -- however, only
six of these touch non-libctf files and only one of them is really the
sort of thing with flaming neon lights saying REVIEW NEEDED over it. If
that's not OK, I can slice off eight patches from the end of it and put
them in another series, but the linker that results will have known bugs
when linking files containing .ctf sections (but none otherwise).

Would it be more convenient to have two series, or one big one? (Or is
it totally irrelevant and I'm worrying about nothing?)

(upside: libctf is much faster after this, and one Solaris-era
limitation is lifted with the demise of the terribly slow ctf_update()
as a user-visible function. Even linking hundred-million-type monster
CTF sections only takes a minute or two, and saner programs are not
slowed perceptibly at all by CTF linking.)

(This is still not a deduplicating CTF linker. I'm working on that now.)