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 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


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