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 Thu, May 30, 2013 at 11:21:08AM +0200, Torvald Riegel wrote:
> On Tue, 2013-05-28 at 20:30 +0200, Florian Weimer wrote:
> > On 05/28/2013 08:09 PM, Václav Zeman wrote:
> > 
> > > If the bottleneck is really in glibc, then you should probably ask them
> > > to fix it. Could the mutex be changed rwlock instead?
> > 
> > rwlocks don't eliminate hardware contention, so I doubt they'd be a win 
> > here.
> 
> Indeed.  Reader-writer locks guarantee the critical section, even the
> readers, that they run mutually exclusive with writers.  So whatever you
> do while holding the lock, the protected data won't change.  That
> restricts what we can do, because we need to actively prevent writers
> from doing things, which means making your read operation visible to
> others (unless you can stop the writers in some other funny ways).
> 
> However, we only seem to need an atomic snapshot here AFAIU, in which
> case we can do stuff like reading the data optimistically, verifying
> that we read consistent data, and retrying if we didn't.

Please look at the mail I've posted in this threads, there are lots of ABI
complexities involved and for many solutions it would require to change both
glibc and gcc (the latter conditionally on glibc), which makes it a long
term process.

The add/sub counters aren't exported from ld.so right now, and aren't updated
atomically (the update is in a mutex guarded code (dl_load_lock) and
dl_iterate_phdr grabs that lock and copies the vars out of it into the
structure for callback).  Plus it is likely undesirable to use TLS
inside of libgcc unwinder (especially because if you can't use initial-exec
TLS model it can't guarantee to be malloc free, which the unwinder would
better be).

	Jakub


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