reducing the contention in dl_iterate_phdr

Thomas Neumann tneumann@users.sourceforge.net
Mon May 18 10:50:27 GMT 2020


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

the __dl_ehframe_find interface you had proposed is fine, I am sorry if
I did not make that clear. My question was if that functionality should
be part of glibc or libgcc. In an ideal world it probably should be in
glibc, because glibc manages the shared libraries, and as you said,
callbacks from glibc are problematic.

However, there are two problems that I see with just migrating to such
an interface:
1) there will be a lot of systems with an old glibc in the foreseeable
future. (And gcc runs on non-glibc systems, of course). Which means that
gcc will need a fallback for these old/non-glibc systems. And there the
whole locking problem comes back again, and we have code duplication.
Handling the lookup in gcc would allow for easier upgrades, and solve
the problem on non glibc systems, too.
2) there are two different kinds of unwind frames: Most are static and
come from shared libraries etc., but some are dynamically generated and
are registered due to JIT code generation. (I am probably biased there
because I use a lot of JITed code). And ideally we want to solve the
contention problem for both cases at once. Which can be done in glibc,
too, but then glibc should also implement the facility to register
dynamic frames. Which would be good anyway, as we could then use one
lookup structure instead of two when unwinding.

Having said that, having an efficient __dl_ehframe_find would be great,
I am completely in favor of anything that helps to provide scalable
exception handling. I am also willing to help with code if needed.

Thomas


More information about the Libc-help mailing list