This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc 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]

[Bug libc/23296] Data race in setting function descriptor during lazy binding


https://sourceware.org/bugzilla/show_bug.cgi?id=23296

--- Comment #17 from dave.anglin at bell dot net ---
On 2019-10-14 8:41 p.m., carlos at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=23296
>
> --- Comment #16 from Carlos O'Donell <carlos at redhat dot com> ---
> (In reply to John David Anglin from comment #15)
>> Created attachment 12039 [details]
>> Patch to fix function descriptor race
>>
>> With this patch, I'm not seeing any segmentation faults due to lazy binding
>> in testsuite.  Still haven't worked on profile code.
> Have you posted this for review on libc-alpha? It's looking like a good
> solution.
Not yet.  Want to finish updating profile code.

I have revised gcc trunk and gcc-9 branch to pass address of descriptor in
register %r22.  The
binutils stub patch has been posted on binutils list and I'm going to install
it soon.

I've been working on changes to try to fix the ordering issues that are present
on PA 2.0 machines.
I have an update to __cffc() that I'm testing.  For it to fully work, it needs
descriptors aligned on
double word boundaries.  This allows descriptor to be updated with atomic
store.

There are subtle issue to PA 2.0 ordering that I don't fully understand and
they aren't clearly described
in architecture book.  When one has a sequence like the following:

        ldd    x
        bve   x
        ldd    y

it would seem to me that the load of y must occur after x.  Otherwise, the non
sequential execution of
loads and stores, and other instructions would be apparent even on UP machines
using simulated threads.
So, it would seem that the branch must be a barrier.  I came to this conclusion
thinking about hppa64 which
uses the above sequence for indirect calls.  It doesn't use an ordered load for
x and there isn't a way to
atomically update x and y together on hppa64 (no quad word store).

Dave

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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