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.