This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PR19826] fix non-LE TLS in static programs
- From: Florian Weimer <fweimer at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org, Torvald Riegel <triegel at redhat dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Tue, 6 Dec 2016 09:03:08 +0100
- Subject: Re: [PR19826] fix non-LE TLS in static programs
- Authentication-results: sourceware.org; auth=none
- References: <or60pqngb7.fsf@livre.home> <cd6f91e1-d494-7c5e-4394-2b6bf3816471@redhat.com> <02df800f-8a00-d132-a90d-dc21c54516c0@redhat.com> <ora8c9im0m.fsf@lxoliva.fsfla.org>
On 12/06/2016 07:56 AM, Alexandre Oliva wrote:
On Dec 2, 2016, Florian Weimer <fweimer@redhat.com> wrote:
What's the status here? It seems that Alexandre committed it on
September 22nd, despite Torvald's objections.
No, I committed the *first* of two patches, that I'd posted on 2016-09-20.
https://sourceware.org/ml/libc-alpha/2016-09/msg00365.html
I'm sorry I reconstructed the history here incorrectly.
This patch broke non-optimized global-dynamic TLS on aarch64 (for
shared builds), as shown by my new tst-tls-manydynamic test case.
Would you please try the second patch and confirm that it fixes the
problem?
If I revert the change to allocatestack.c, the test case passes.
What you're hitting is most likely the DTV resizing race
condition described in the comments there, at the '(**)' note.
It's not even a race. The test case serializes DTV access externally,
and still fails. So the comment about a race is rather misleading.
Thanks,
Florian