This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/23296] Data race in setting function descriptor during lazy binding
- From: "dave.anglin at bell dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 15 Oct 2019 12:00:55 +0000
- Subject: [Bug libc/23296] Data race in setting function descriptor during lazy binding
- Auto-submitted: auto-generated
- References: <bug-23296-131@http.sourceware.org/bugzilla/>
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.