On Tue, May 28, 2013 at 8:50 PM, Ryan Johnson <ryan.john...@cs.utoronto.ca> wrote: > > For example, it should be reasonably safe to let __cxa_allocate_exception > call dl_iterate_phdr in order to build a list of object headers valid at the > time unwind begins. It already calls malloc, so allocating space for a cache > (holding pointers to at most a few dozen object headers) wouldn't be so > terrible; __cxa_free_exception could release the space after the dust > settles. In order to optimize non-throw uses of unwinding, it might make > sense to build the cache somewhere besides __cxa_allocate_exception, but the > basic concept doesn't change.
Actually, when everything is working correctly with modern tools on a GNU/Linux system, the unwind code never calls malloc. That is a good thing, as otherwise it would be unsafe to throw from a signal handler. > [1] I'd also move the call to _Unwind_Find_registered_FDE after the cache > check, so it becomes a fallback (thus avoiding the libgcc mutex lock in the > common case of "newer" executables and shared libraries). Unless by some > cruel twist of history, there exist out there objects that register their > FDEs manually *and* provide .eh_frame whose invalid entries must be ignored? Moving _Unwind_Find_registered_FDE down seems reasonable to me. I can't think of any reason why it wouldn't work. Ian
