Excessive calls to iterate_phdr during exception handling

[Ryan Johnson]

On 28/05/2013 11:49 PM, Ian Lance Taylor wrote:
> On Tue, May 28, 2013 at 6:19 PM, Ryan Johnson
> <ryan.johnson@cs.utoronto.ca> wrote:
>> That last point makes me really wonder why we bother grabbing the mutex
>> during unwind at all... at the very least, it would seem profitable to
>> verify the object header cache at throw time---perhaps using the nadds/nsubs
>> trick---and refresh it with a call to dl_iterate_phdr if need be, then do
>> the rest of unwind lock-free, ignoring deranged users who dlclose live code
>> [2].
> It's not that simple, as the cache is simply mapped in from the
> object.  So we need to ensure not only that the cache is valid when we
> start to read it, but that it remains valid while we are reading it.
> It's hard to see how to do that without some sort of lock.
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?

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?

Ryan