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

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

On 7 May 2019, Joseph Myers said:

> On Fri, 3 May 2019, Nick Alcock wrote:
>
>> > This means libctf should be portable to the same range of hosts as 
>> > binutils, all of which can be used as hosts for cross toolchains for a 
>> > range of targets (ELF and non-ELF).  For example, it should be portable to 
>> > hosts such as MinGW or OS X.
>> 
>> Seems sensible. It might lose some functionality, though, at least to
>> start with. (Say, sharing string tables with the overarching container,
>> opening CTF files by handing them an fd to a containing binary, etc.
>> There are alternatives callers can use in all these cases.)
>
> I don't think that functionality should depend on the host, though it 
> might depend on the target.

I agree with all of that. We don't want cross-tools to generate
different output to non-cross tools, etc.

I guess that means I might *have* to figure out how to do the (very
limited) ELFish things currently being done with libelf with bfd
instead. (And I just noticed that bfd does in fact have useful texinfo,
so I can read that and most of my bfd fear should go away. I have no
*idea* why I thought it had no texinfo docs. Probably some out of date
fifteen year old memory fooling me or something.)

... ok with docs BFDizing this should be much less terrifying than I
thought.

I was also a bit worried about circular dependencies, but I don't think
there are any: we'll have {ld, binutils, gdb} -> libctf -> bfd, which is
fine, but no link from bfd back to libctf.

>> I'll probably arrange for the deduplicating linker plugin to be
>> ELF-only, at least to start with, because I have no way to test on
>
> A plugin is about the only thing I'd expect to depend on the host (in that 
> you'd need different build system logic to build a non-ELF shared object).  

Yes, except that if the host is horribly limited I'm starting to not
care about it. If mingw *does* have writable memory mappings, I'm
happy...

>> If there are really still platforms relevant outside industrial museums
>> without mmap(), we can rethink this, but I bet there aren't, or that any
>> such platforms aren't going to be storing huge numbers of CTF containers
>> in any case. (The use case for this is if you have so many TUs that you
>> can't store one per section without risking blowing the 64K section
>> limit. Any machine new enough to be dealing with anything in that size
>> range is going to have mmap() as well, right? Or something we can use
>> instead of it with similar semantics...)
>
> MinGW has similar APIs such as MapViewOfFile.  It's not mmap.

... and that's near enough I think. It looks like you can at least use
it to create files via ordinary memory I/O, just like mmap(): it has
weird restrictions but they're no harder to deal with than the
page-granularity restrictions that go with mmap() anyway. So I don't
need to rewrite all the archive code to use file I/O instead :)

>> 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.
>
> I don't see why such functions should depend on whether the host is ELF at 
> all.  On the target, yes, but not on the host.

Oh true. I've constantly mixed up host and target for as long as I've
been using GNU tools, and I fear that after 25 years of getting it wrong
I'm not going to start getting it right any time soon. (I don't know
why. It's not as if the names are unclear.)

I did, of course, mean 'target' there, which does mean BFDizing to drop
the elfutils dependency.

I'll look at that soon. (Most of the other issues you raised I have
already fixed locally, and the fixes will be in the next patch rev.)