[PATCH 00/10] libctf: cleanups, speedups, and bugfixes (one needing review)

[Nick Alcock]

The time has come to drop a bunch of code debt.

Implementing the deduplicating linker involved implementing replacements for
several existing pieces of libctf machinery.  In most cases I left the old
machinery around so that its other users wouldn't be disrupted by any bugs and
because I wasn't confident that I had enough of a testing set to be sure that
the new stuff worked reliably.

Courtesy of rebuilding (at last count) almost a thousand Gentoo packages with
-gctf (eschewing only the kernel, which needs special support not in Gentoo
kernels: even glibc and ld.so got the CTF treatment), I think I can say that the
new stuff works well enough that the old stuff can go.  This also reduces the
amount of code that peeks directly at the guts of CTF, which is useful
preparation for the upcoming CTF format v4.

So this patch series ditches most of the _iter iterators and reimplements them
in terms of the newer _next iterators, fixing one bug in ctf_archive_next in the
process, and removes the (extremely inefficient and slow) nondeduplicating CTF
linker, simplifying ctf-link.c quite a lot.  (ld has no way to invoke the
nondeduplicating linker other than an undocumented environment variable for
debugging purposes; the ctf_link API has a CTF_LINK_NONDEDUP flag to enable it
which is now a NOP, though in future, if more expensive algorithms turn out to
be beneficial in deduplicating CTF linking, it might be repurposed to mean "save
time by deduplicating less".)

This lets us replace the type mapping machinery used to determine what types on
the link input translate to what types on the link output, moving from one
designed for the nondeduplicating linker and ctf_add_type to one that directly
queries the internal data structures of the deduplicator, saving about 20% of
link time with no loss of functionality.

There are a few bugfixes here that fell out of the Gentoo rebuild, of which one
is serious: a string refcounting bug which led to us sometimes emitting the type
for one symbol and attaching it to another.  Sometimes that other symbol was of
a different st_type: *that* led to the CTF linker emitting a warning and the
symtypetab section becoming irretrievably corrupted (the names and thus types of
all symbols with an index >= the index in the warning would be wrongly
computed).  That fix alone should probably go into 2.36, and might need a bz
bug: I'm not sure if libctf bugs count as user-visible before the CTF-generating
GCC gets in.

That last fix may need a tiny bit of review due to a few lines of bfd changes,
admittedly in code that only libctf uses.  I can verify that every case where
this bug was known to appear is fixed by this (at least one binary in each of
twelve packages out of 860 in my Gentoo world rebuild).

(As ever, I'm happy for anyone to review anything I post.)

Nick Alcock (10):
  libctf: ctf_archive_next should set the parent name consistently
  libctf: reimplemement many _iter iterators in terms of _next
  libctf: fix ChangeLog date
  libctf, include: remove the nondeduplicating CTF linker
  libctf: remove reference to "unconflicted link mode".
  libctf: add a deduplicator-specific type mapping table
  libctf: minor error-handling fixes
  libctf: fix signed/unsigned comparison confusion
  libctf: free ctf_dynsyms properly
  bfd, ld, libctf: skip zero-refcount strings in CTF string reporting

 bfd/ChangeLog        |   4 +
 bfd/elf-strtab.c     |   2 +
 include/ChangeLog    |   5 +
 include/ctf-api.h    |   3 +-
 ld/ChangeLog         |   4 +
 ld/ldelfgen.c        |  16 +-
 libctf/ChangeLog     | 108 +++++++-
 libctf/ctf-archive.c |  70 ++----
 libctf/ctf-create.c  | 111 ++++++++-
 libctf/ctf-dedup.c   | 215 ++++++++--------
 libctf/ctf-dump.c    |   4 +-
 libctf/ctf-impl.h    |  17 +-
 libctf/ctf-link.c    | 577 ++++++++++---------------------------------
 libctf/ctf-types.c   | 115 ++++-----
 14 files changed, 550 insertions(+), 701 deletions(-)

-- 
2.30.0.252.gc27e85e57d