[PATCH 00/19] libctf, and CTF support for objdump and readelf

[Nick Alcock]

On 3 May 2019, Florian Weimer verbalised:

> * Nick Alcock:
>
>>   - a very compact association between the ELF symbol table and CTF.
>>     No symbol table indexes are recorded: all are implied: the
>>     data-object section is as compact as possible, containing nothing
>>     but a stream of type IDs describing the type of data symbols in
>>     symbol table order.
>
> Is this for GNU/Linux?
>
> On GNU/Linux, DWARF unwinding information (in the form of
> PT_GNU_EH_FRAME) is not optional, it is required by the ABI (although
> many people pretend it's not, resulting in crashes or worse).
> 
> I'm worried that we have to add both in the future, DWARF data and CTF
> data, which would be rather bad.

I'm fairly sure they are quite distinct. CTF doesn't even try to record
unwinding information, or anything like it, but rather lets you
introspect into datatypes (not into the call stack, not into function
arguments, but into C types). Even the backtrace section, if and when we
add it, isn't going to do what DWARF unwinding info does: its purpose is
more to let debuggers find function arguments' values and types on the
call stack in a form much smaller than DW_TAG_call_site. Wherever
possible, if we find we need something the unwinding info is providing,
we'll point into that instead, to save space.

The one overriding rule of CTF is 'never duplicate anything you can find
elsewhere'. We already use strings from the ELF string table whenever
possible: if we ever come to need unwinding info, we'll definitely use
the DWARF unwinding info, because it is not stripped from binaries, so
its presence can be relied upon.

(Also, CTF is meant to be very small, small enough to ignore and to
leave even in stripped binaries except in very constrained environments.
I'm almost certain that it'll be *much* smaller than the DWARF unwinding
information. It certainly is in all cases I've examined so far. But
you're wise to reserve judgement on this until we have GCC and linker
support in place so you can see it for yourself.)