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 Wed, 2013-05-29 at 10:06 -0400, Ryan Johnson wrote:
> On 29/05/2013 9:41 AM, Ian Lance Taylor wrote:
> > 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.
> Per-thread cache, either allocated and populated at the start of every 
> unwind, or maintained in TLS with version checks against the dl 
> adds/subs counts. The former reduces the lock grabbing to one per 
> unwind; the latter would virtually eliminate locking during unwind, but 
> would require changes to libc to expose the adds/subs counts in some 
> lock-free way.

I haven't looked at the actual use case, but if we're really mostly
interested in an atomic snapshot of a simple data structure, then there
are various ways to do that more efficiently than via holding a lock
while doing the snapshot.  In particular, if the cache is read-mostly
and always mapped, there's a good chance one can build something more
efficient without this becoming too complex.  The version checks Ryan
mentions are one option.  If there's a need, I can help with the
synchronization bits.

Torvald


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