This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fixing the distribution problems with TLS and DTV_SURPLUS slots.
- From: Rich Felker <dalias at libc dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Adam Conrad <adconrad at ubuntu dot com>, Alexandre Oliva <aoliva at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Mon, 6 Oct 2014 16:35:27 -0400
- Subject: Re: Fixing the distribution problems with TLS and DTV_SURPLUS slots.
- Authentication-results: sourceware.org; auth=none
- References: <5432EFF9 dot 5020602 at redhat dot com>
On Mon, Oct 06, 2014 at 03:39:37PM -0400, Carlos O'Donell wrote:
> Adam,
>
> I'm sitting on this patch in Fedora, and you asked me to send it
> upstream. Unfortunately I don't think it is right solution for
> upstream.
>
> Firstly, please don't respond with "But DSOs using TLS IE accesses
> are not allowed."
That's what I wanted to say, but I'll refrain.
> Do we grow the DTV_SURPLUS knowing it's a bandaid?
Considering that the growth is not that much memory, I have no
objection, but I hope this will be accompanied by a commitment to push
for moving everything to TLSDESC. Ideally this would include making ld
produce a warning (to be converted to an error somewhere down the
line) when producing a .so with TLS IE model.
> WARNING: On AArch64 or any architecture that uses the generic-ish
> code for TLS descriptors, you will have further problems. There
> the descriptors consume static TLS image greedily, which means
> you may find that there is zero static TLS image space when you
> go to dlopen an application.
dlopen an application? I'm not understanding the whole issue here, but
it's probably not that important to considering the change you want to
make, anyway, is it?
Rich