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: Torvald Riegel <triegel at redhat dot com>
- To: Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>
- Cc: Ian Lance Taylor <iant at google dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 30 May 2013 11:16:52 +0200
- 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> <CAKOQZ8ykXBgWH6EtuiQ9s42mhWdahfTwHJ1uhxp9DRGrrJ9RPQ at mail dot gmail dot com> <51A60B77 dot 8000402 at cs dot utoronto dot ca>
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