libctf linking against different libbfd builds, but using the same soname

[Nick Alcock]

On 22 Nov 2019, Matthias Klose verbalised:

> I made a first attempt at packaging binutils trunk and libctf.  Two new shared
> libraries are installed, libctf and libctf-nobfd.  libctf-nobfd is the same
> library for native builds, and for builds targeting other architectures, however
> the libctf builds are differing, because they link to different libbfd
> libraries.

... I suppose so. Does this matter?

For a cross build, I'd expect libctf.so.* and libctf-nonbfd.so.* to go
into an arch-triplet-named sysrooted libdir anyway
(/usr/aarch64-unknonwn-linux-gnu/lib etc): the libdir copy is usually
reserved for native builds. I guess Debian multiarch makes this a bit
different, but the general rule of not stuffing cross shared libraries
in the same libdir as non-cross shared libraries surely remains. (If I
have to do something special to make that happen, and I've not noticed,
I'd be happy to do it. Multiarch is a wonderful thing and should be
encouraged.)

>            The packages for Debian/Ubuntu are built with the attached patch,
> and setting BFD_SOVER_EXT to "-system" for native builds, and to
> "-$(TARGET_ARCH)" for cross binutils.  Ending up now with conflicting sonames
> for the native and cross libctf builds. Now I think I should extend the patch
> below to encode the same information into the libctf soname, so that I am able
> to distinguish between the native and the various cross builds. Is this correct,
> or can you discard the cross libctf builds and use the native build instead?

The only thing we use libbfd for in libctf is to read .ctf sections out
of BFD-readable objects, and tie them up with likely-relevant string and
symbol tables in the enclosing object. As long as the native BFD can
read the relevant objects, nothing bad would happen if you used the
native one rather than the cross one.

However... if you build with --enable-shared, ld ends up linking against
libctf as well (obviously) as bfd. I'm fairly sure bad things would
happen if libctf was linking against a *different* bfd than the ld that
used it, at least unless we tried to hide the symbols used internally to
libctf (using DT_GROUP or -Bsymbolic or something: that's nonportable,
of course, which might cause trouble if you built an ELF cross on a
non-ELF platform... and it feels like papering over the problem.)

Basically, BFD usage is a small part of libctf, and I was really hoping
that I wouldn't have to perturb the entire soname or do something else
massively disruptive just because of the library we're using to pull
sections out of executables. But really as long as users can just say
-lctf to link with it I guess it's not too problematical if the SONAME
they end up linking with is cross-specific. (It shouldn't be a
constantly-changing soname, though. Unlike libbfd, we have a stable
API/ABI in libctf, at least mostly, and I'd like to stick with that if
possible, with exceptions for newly-added and still evolving bits like
ctf_link_*().)

> The other question I didn't look into detail yet: Does the linking of libctf
> against libbfd change any of the libctf ABI?

Some symbols (e.g. ctf_open(), ctf_fdopen()) will not be available at
all in the absence of BFD, but those symbols are always the same if
present, and act the same: the crossness of the BFD doesn't affect that.

The most that does happen is that a non-ELF libctf isn't going to dig
out associated string and symbol tables, but then since non-ELF objects
don't try to share their CTF string tables with the enclosing (non-ELF)
object file, nor have mappings from symtab entries to CTF type IDs, this
should have no discernible consequences. (And if we did gain non-ELF
support for some of those, ctf_open etc would start working for them as
well.)

(All BFD usage in libctf is localized inside libctf/ctf-open-bfd.c. Its
use is not very complicated: the most we are doing is finding CTF
sections and figuring out any associated strtab and symtab. :) )