This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules
On Wed, 2019-07-03 at 20:56 -0400, Frank Ch. Eigler wrote:
> > Some of the binaries use libebl, and although libebl is linked into libdw.so,
> > the libebl symbols are not exported by libdw. So, libebl is linked in
> > statically for the binaries.
> >
> > This is why I suggested exporting those symbols from libdw.so. (I also
> > considered adding a libebl.so, but that would have a circular dependency with
> > libdw.so, so they might as well be combined).
>
> Ah, thanks for the (re-)explanation. IMHO, if the API is useful
> enough to be used by mainline elfutils binaries, it is useful enough
> to be used by others. So a +1 from me for solib-exporting them.
The API is kind of useful enough to be used by the elfutils binaries
directly (or they would use it). But that doesn't make them good,
supportable API that we should expose through libdw.so. That would mean
we promise they are fixed and supported essentially forever. It means,
they are quick hacks that might work for now for internal use only.
It might still be a good idea to expose/move some into libdw.so. But we
should carefully review them one by one. This was done for example for
the ELF/DWARF string table functions (Dwelf_Strtab and Dwelf_Strent).
Or see my recent patch that replaces ebl->name with with a new libdw.so
function dwelf_elf_e_machine_string (which works for any ELF e_machine
value, not just for those which have a backend implementation):
https://sourceware.org/ml/elfutils-devel/2019-q2/msg00130.html
Cheers,
Mark