[PATCH 00/12] CTF symbol functionality

[Nick Alcock]

On 25 Oct 2020, Nick Alcock said:

> This patch series lets you look up the types of symbols in ELF objects in
> the func info / data object CTF sections (hereafter, "symtypetab sections")
> by just compiling with -gt with a suitable compiler (see below) and linking
> them as usual, then opening the CTF dict as usual76 with ctf_open and
> calling ctf_arc_lookup_symbol with a dynamic symbol index: you get a
> ctf_id_t back which you can chase around the type graph and look up
> properties of.  Function symbols and data symbols that are function pointers
> both yield types of kind CTF_K_FUNCTION.
[...]
> Things that need review:
>
> Patches 1 and 2 touch things that use a ctf_file_t to adapt to some type
> renamings, but nothing more: they are purely mechanical.  Patch 3 touches
> objdump and readelf, even if only the CTF parts.
>
> Patch 4 is a fairly invasive patch (written only yesterday) that redoes the
> CTF symtab hookery in bfd and ld: we were, it turns out, using the wrong
> symtab and strtab for CTF the whole time, but we must not use .symtab and
> .strtab because they are stripped out!  This change switches over to use
> .dynsym and .dynstr (which is what Solaris did), but this is a bit more
> fiddly because .dynstr is built up in pieces in many places and is never
> present in a single unified lump like the symtab: so every place that swaps
> symbols out to the dynsym needs a hook call added before it.  (I'd prefer to
> have hooked in inside swap_symbol_out, but that doesn't know if its symbol
> is going into the dynsym or not and has no access to the
> bfd_link_callbacks).  We keep a hook in place for hooking into .symtab
> additions as well as .dynstr, but that hook is NULL for now because we don't
> need it.

Gentle ping?

(Again, patches 1 and 2 (possibly) and 4 (definitely) need review.)