This is the mail archive of the libc-alpha@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]

Re: [PR19826] fix non-LE TLS in static programs

From: Florian Weimer <fweimer at redhat dot com>
To: "Carlos O'Donell" <carlos at redhat dot com>, Alexandre Oliva <aoliva 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: Fri, 2 Dec 2016 17:32:58 +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> <eca1ea03-4fad-7047-6c6a-81f6b48c493f@redhat.com>

On 12/02/2016 05:25 PM, Carlos O'Donell wrote:

This patch broke non-optimized global-dynamic TLS on aarch64 (for
shared builds), as shown by my new tst-tls-manydynamic test case.


Does reverting Alex's patch fix tst-tls-manydynamic?

It's sufficient to revert the patch to nptl/allocatestack.c. I don'tknow if it is really needed, I and I have no idea how to makeinitialization at this point safe because the threads themselves couldbe using the DTV concurrently, so we cannot enlarge it.

I filed <https://sourceware.org/bugzilla/show_bug.cgi?id=20915> so thatwe keep track of this regression and fix it before the release.


Thanks,
Florian

Follow-Ups:
- Re: [PR19826] fix non-LE TLS in static programs
  - From: Carlos O'Donell
- Re: [PR19826] fix non-LE TLS in static programs
  - From: Alexandre Oliva

References:
- Re: [PR19826] fix non-LE TLS in static programs
  - From: Florian Weimer
- Re: [PR19826] fix non-LE TLS in static programs
  - From: Carlos O'Donell

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