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

[Nick Alcock <nick.alcock@oracle.com>]

On 24 May 2019, Pedro Alves spake thusly:

> On 5/3/19 3:23 PM, Nick Alcock wrote:
>>> * Use of elf.h.  Non-ELF hosts won't have such a header.  You should be 
>>> working with the existing include/elf/*.h definitions of ELF data 
>>> structures in binutils.
>> This is all for build hosts that aren't ELF, right? I don't think we can
>> reasonably expect ctf_open() or ctf_fdopen() to work for anything but
>> raw CTF files on non-ELF hosts, given that by their very nature these
>> functions are getting CTF data out of ELF sections, and non-ELF formats
>> don't necessarily support anything like the named section concept ELF
>> has got at all.
>> 
>> The only other ELF-specificity is looking up types by symbol table
>> offset. Again, I don't know enough about non-ELF platforms to know if
>> this concept is even practical there, which would mean the data object
>> and function info sections would be empty on such hosts, and
>> ctf_lookup_by_symbol(), ctf_func_info() and ctf_func_args() would not
>> function or would be excluded from the set of exported symbols entirely.
>> 
>> This would reduce libctf's utility, but not eliminate it: external
>> systems can still look up types by name or CTF type ID even if they
>> can't do it by symbol.
>
> Even if you only want to support CTF on ELF containers, a cross
> binutils build hosted on e.g., Windows, targeting an ELF port, should
> still be able to use the CTF.  That's why it is important to not rely
> on host headers for ELF definitions.  It wasn't clear to me from
> your remarks above whether the cross use case is considered?

My v2 posting (already out) and v3 (to be posted today, with a
bfdization layer that actually works and a bunch of interface changes to
make it more useful, and an example use in objdump) appear in my testing
to work on mingw, at least. I think that's a non-ELF-capable host.

Avoiding relying on host ELF headers is also important because the ELF
header I was unthinkingly relying on isn't portable outside glibc on
Linux and perhaps Solaris, and that's definitely not portable enough.

(We do still *need* a few lines of stuff from ELF headers, because the
low-level symbol lookup parts of libctf cannot rely on having a bfd
available, so we have to do symbol walkiing by hand -- but we don't need
the host to provide those few lines, and we do use BFD to get section
content etc when possible now.)