This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Excessive calls to iterate_phdr during exception handling
- From: Ian Lance Taylor <iant at google dot com>
- To: Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 28 May 2013 21:01:42 -0700
- Subject: Re: Excessive calls to iterate_phdr during exception handling
- References: <51A3DC25 dot 90401 at cs dot utoronto dot ca> <CAKOQZ8y36SyH5DgU9ZLT1AuVkd0MLOn7ZrFzZ2aoz4CQZV3txw at mail dot gmail dot com> <51A557B4 dot 7080202 at cs dot utoronto dot ca> <20130529030503 dot GK6878 at bubble dot grove dot modra dot org> <51A57B05 dot 2060402 at cs dot utoronto dot ca>
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