reducing the contention in dl_iterate_phdr

Florian Weimer
Mon May 18 10:21:32 GMT 2020

* Thomas Neumann:

>> I still think that an explicit function to perform the lookup on
>> behalf of libgcc_s is the right direction.
> but that means moving quite a bit of libgcc into glibc. At least the
> logic called from _Unwind_IteratePhdrCallback.

Only the part that is related to ELF parsing.  This seems to be pretty
well aligned with what the dynamic loader does in general.  Once the
relevant PT_GNU_EH_FRAME segment is located in memory, control returns
to libgcc_s.  There is still no DWARF parsing in the dynamic loader.

glibc itself will benefit from such change, eventually leading to
speedups in certain forms of dlsym, too.  (We have caller-sensitive
functions that need to determine the object in which a caller is

> And to make this efficient in the presence of JITed code, you would
> have to include parts of unwind-dw2-fde.c, too, such that manually
> registered unwind frames can be processed with the same framework.

The registered frame information changes would still be beneficial, I
think.  If there is no such information, we can just skip over that part
of the code (no barrier necessary).

A low-hanging fruit is a fast path for identifying libcc_s itself
directly because it always shows up in backtraces.  This needs some
linker hackery to get the magic constants, but it can be done today,
without glibc changes.

> An alternative would be to offer a new dl_iterate_phdr variant
> (tentatively called dl_iterate_phdr_read) to takes just the read lock,
> while the existing dl_iterate_phdr continues to take the lock in
> exclusive mode. That would allow libgcc to opt-in to an interface with
> less contention. Of course that would require changes to libgcc, too, to
> make their cache thread safe, but it would not break existing programs.

Please have a look at the interface sketch on the GCC thread.  There is
no observable lock anymore in that interface.

> For an even better implementation I think it would be good if glibc had
> an interface for callbacks that are called after every dlopen and
> dclose. Because that would allow libgcc to build an index over the
> lookup tables. But that is a much more invasive change.

Sorry, I don't think that libgcc_s should do any ELF processing.
Callbacks from the dynamic linker are always problematic because what
what you can do from them is very limited and hard to describe.  For
example, you would not be able to call malloc from these interfaces
because an interposed malloc might itself use the same dynamic linker


More information about the Libc-help mailing list