https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There are 2 locks, one is internal to libgcc* and used to guard the old style
FDE registry which should be only rarely used. This one perhaps could be
transformed into a rwlock, and/or handle the common case where nothing is
registered using the old registry somehow without the lock, just with some
atomic comparison.
The second one is inside of glibc, in the dl_iterate_phdr call, to change
anything here synchronized changes between glibc and gcc would be required, or
do some changes internal to glibc only.
Right now glibc uses here a recursive global lock, dunno if it would be
possible to use recursive rwlock instead and whether it wouldn't slow down
dlopen/dlclose way too much.
The dl_iterate_phdr API these days provides (non-atomic) long long counters
counting number of dlopens and number of dlcloses, so the unwind code can
determine if it can use the caches (if no dlopen/dlclose happened since last
time) or not. But these are computed inside of the locked code. The problem
with e.g. making these counters atomicly updated (not possible on all arches,
even i486 can't do that, and many others) and add some API to query those is
that that still doesn't guarantee that in between checking these counters and
looking stuff the library isn't dlclosed by some other thread. Though, for
unwinding, if some code address is seen in the backtrace, then it better not be
dlclosed until the unwinding is done.
