[RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

Omar Sandoval osandov@osandov.com
Mon Jul 8 21:02:00 GMT 2019

On Mon, Jul 08, 2019 at 10:48:52PM +0200, Mark Wielaard wrote:
> 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.

Hi, Mark,

> 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.

This makes sense. One thing I noted in the patch to export the libebl
symbols [1] is that exporting them wouldn't necessarily mean supporting
them as an official API. However, I can see why you'd be concerned with
developers using them anyways.

My patch submission last Friday [2] still works without the patch to
export the libebl symbols, the only drawback being the size increase, of

> 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

I imagine that little by little, most of the libebl functionality could
be converted in this way, and that's how we could chip away at the size
increase of the elfutils binaries.

Do you have any objections to patches 1-4 of my submission [2]?

Thanks for the timely response!

1: https://sourceware.org/ml/elfutils-devel/2019-q3/msg00022.html
2: https://sourceware.org/ml/elfutils-devel/2019-q3/msg00020.html

> Cheers,
> Mark

More information about the Elfutils-devel mailing list