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:41:20 -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> <CAKOQZ8zWprm8+BuhUyKh7zZJcvFb5ejhmzzFNQV-cFZo9uoFQw at mail dot gmail dot com> <51A57DD3 dot 80504 at cs dot utoronto dot ca>
On Tue, May 28, 2013 at 9:02 PM, Ryan Johnson
<ryan.johnson@cs.utoronto.ca> wrote:
>
> Maybe I misunderstood... there's currently a (very small) cache
> (unwind-dw2-fde-dip.c) that lives behind the loader mutex. It contains 8
> entries and each entry holds the start and end addresses for one loaded
> object, along with a pointer to the eh_frame_header. The cache resides in
> static storage, and so accessing it is always safe.
>
> I think what you're saying is that the p_eh_frame_hdr field could end up
> with a dangling pointer due to a dlclose call?
Yes, that can happen.
> If so, my argument is that, as long as the cache is up to date as of the
> start of unwind, any attempt to access a dangling p_eh_frame_hdr means that
> in-use code was dlclosed, in which case unwind is guaranteed to fail anyway.
> The failure would just have different symptoms with such a cache in place.
>
> Am I missing something?
I think you're right about that. But what happens if the entry is not
in the cache? Or, do you mean you want to look in the cache before
calling dl_iterate_phdr? That should be safe but of course you still
need a lock as multiple threads can be manipulating the cache at the
same time.
Ian