https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #16 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
I have committed a fix:
commit 6e56633daae79f514b0e71f4d9849bcd8d9ce71f
Author: Thomas Neumann
Date: Fri Dec 9 18:23:44 2022 +0100
initialize fde objects lazily
When registering an unwind frame with __register_frame_info_bases
we currently initialize that fde object eagerly. This has the
advantage that it is immutable afterwards and we can safely
access it from multiple threads, but it has the disadvantage
that we pay the initialization cost even if the application
never throws an exception.
This commit changes the logic to initialize the objects lazily.
The objects themselves are inserted into the b-tree when
registering the frame, but the sorted fde_vector is
not constructed yet. Only on the first time that an
exception tries to pass through the registered code the
object is initialized. We notice that with a double checking,
first doing a relaxed load of the sorted bit and then re-checking
under a mutex when the object was not initialized yet.
Note that the check must implicitly be safe concering a concurrent
frame deregistration, as trying the deregister a frame that is
on the unwinding path of a concurrent exception is inherently racy.
libgcc/ChangeLog:
* unwind-dw2-fde.c: Initialize fde object lazily when
the first exception tries to pass through.
