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

[Pedro Alves <palves@redhat.com>]

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?

Thanks,
Pedro Alves