[PATCH v3 REVIEW 25/33] bfd, ld: add CTF section linking

[Nick Alcock]

.. now I'm going over it in detail, this is a really helpful review,
thank you!

On 9 Sep 2019, Alan Modra uttered the following:
>>  - We might well have memory leaks: we open the CTF sections for the
>>    input files and then never close them again.  Should we? ld does seem
>>    to operate on the basis that input files live forever so it doesn't
>>    matter if they are never freed...
>
> You might want to do something depending on the state of
> link_info.keep_memory.

I think we want to free them regardless. CTF sections are unusual in
that they are dynamically-allocated content in the_bfd->contents.
Everything else that sets "contents" except for
lang_do_version_exports_section seems to set it to the contents of some
other thing somewhere else: e.g. if SEC_IN_MEMORY is set this is the
bfd_in_memory structure populated by _bfd_from_remote_memory.

One thing that SEC_IN_MEMORY does *not* do is make any attempt to free
anything, ever.

So for now I'm just setting SEC_IN_MEMORY on the output: if a future
change to bfd starts to free things with that set, the output section
will be properly freed as a consequence.

As for the input CTF sections, they're freed when we close the output
ctf_file_t after generating the output section contents, since the
ctf_link_add_ctf API takes ownership of the CTF you pass in on behalf of
the target ctf_file_t. So that's fine as it is (though I am now setting
the input the_ctfs to NULL to avoid the possibility of dereferencing a
freed pointer later on).

>>  - I'm fairly unhappy that I have to modify the default linker script,
>>    because that means that any project wanting CTF support and providing its
>>    own linker script will have to change.  But without doing this, we
>>    never get an input->output mapping and the CTF sections are simply never
>>    emitted.  This seems to be because non-loaded sections are simply thrown
>>    away in the elf32.em orphan-assignment code: but even if it might be
>
> That isn't true.  Non-alloc orphans are handled fine.  I suspect what
> you're running into is removal of zero size sections by
> strip_excluded_output_sections.

Rather than the horrible 'set it to size 1' thing I was maundering about
last week, it looks like I can fix this by flipping SEC_LINKER_CREATED |
SEC_KEEP, which is much neater. The result seems to work.


... after days of cursing, I think I have shared libraries working, too,
using the same mechanism as bfd (so configure --enable-shared works, no
need for a new flag or anything: technique brazenly stolen from
opcodes/). I have split the library in two, libctf.la and
libctf-nobfd.la (horrible name, alternatives solicited as long as the
BFD-using one is the easy one to remember) so that readelf and anything
else that wants to avoid BFD can easily do so.

Right now I'm just building two libraries with nearly identical content:
having libctf.so depend on libctf-nobfd.so for most of its content is
only practical if there is some portable way of exposing
libctf-nobfd.so's symbols to libctf.so's consumers, which seems quite
unlikely (it happens without needing to do anything on ELF platforms,
but what about others?). It's not a very big library so no harm is done,
I suspect, and even if you load both copies nothing bad happens because
one lib is a subset of the other so we don't care what symbol
interposition does to it :)

Both use symbol versions, but the soname is .0 for now until I have
nailed down the link API and written the deduplicator.

Also adjusted to your recent {elf-generic,elf}.em -> ldelf changes.
Testing now, will post the next round on Monday if it works.