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: Wed, 29 May 2013 06:45:52 -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> <CAKOQZ8zsdmp4rkpFMwuzbds8F-sdA-T3PmXyZxkLC1x6CZ4QQQ at mail dot gmail dot com> <51A58100 dot 5050407 at cs dot utoronto dot ca>
On Tue, May 28, 2013 at 9:16 PM, Ryan Johnson
<ryan.johnson@cs.utoronto.ca> wrote:
> On 29/05/2013 12:01 AM, Ian Lance Taylor wrote:
>>
>> 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.
>
> Hmm... How recent is "modern" ? Because the only obvious
> __cxa_allocate_exception in the gcc-4.8 sources
> (libstdc++-v3/libsupc++/eh_alloc.cc) sure seems to call malloc, and the
> traces I got from throwing in code compiled by both gcc-4.6 and gcc-4.8
> (gold linker) show calls to malloc as well.
Sorry, you're quite right. I've gotten out of the habit of thinking
of C++. The unwind code does not call malloc, and that is important.
But actually throwing an exception from C++ does call malloc, and that
is problematic when trying to throw from a signal handler. I
shouldn't have used that as an example.
It's important that the unwind code proper does not call malloc so
that we can reliably get stack traces from signal handlers,
specifically from the SIGPROF signal.
Ian