This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Excessive calls to iterate_phdr during exception handling


On Tue, May 28, 2013 at 8:50 PM, Ryan Johnson
<ryan.johnson@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]