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: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Adam Conrad <adconrad at ubuntu dot com>, Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Fri, 10 Oct 2014 10:33:53 -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> <orzjd8xv5v dot fsf at free dot home> <5436A03F dot 2050008 at redhat dot com> <20141010001525 dot GV23797 at brightrain dot aerifal dot cx> <or38aw9k3h dot fsf at free dot home>
On Fri, Oct 10, 2014 at 09:37:22AM -0300, Alexandre Oliva wrote:
> On Oct 9, 2014, Rich Felker <dalias@libc.org> wrote:
>
> > On Thu, Oct 09, 2014 at 10:48:31AM -0400, Carlos O'Donell wrote:
>
> >> What if the module author can never tolerate GD-like performance and
> >> would rather it fail than load and run slowly e.g. MESA/OpenGL?
>
> > This is not the module author's decision to make. If the user wants to
> > run, the user should be able to run.
>
> Granted: user can always LD_PRELOAD the module that defines the variable
> to ensure it gets to IE.
Yes, but that actually doesn't work right when the library's symbols
are never intended to reach the global namespace because it comes in
as a dependency of an RTLD_LOCAL dlopen. For this usage to be
reliable, tt would be necessary to have something like LD_PRELOAD
("LD_PREREQ"?) but that opens the library and allocates static TLS for
it at startup time, but defers ctor execution and visibility of the
symbols until something explicitly loads/needs it.
> > I think (d) should be omitted, and a step (f) should be added: patch
> > binutils to disallow the creation of .so files with IE TLS.
>
> I wouldn't go as far as disallowing it, since there are perfectly
> legitimate cases of IE accesses in dynamic libs. The most obvious
> example is glibc plugins that access libdl.so or libc.so symbols, that
> are always IE, but any app that provides symbols in IE modules and wants
> to use IE to access them even from plugins should have no problem doing
> so.
I agree with this claim, but question whether there's any practical
benefit of doing so.
> It's not like TLSDesc GD is as efficient as IE; it's just pretty
> close if the variable is in static TLS. If someone wishes to structure
> their app to squeeze a little bit of extra performance by making
> legitimate uses of IE, why not let them?
If you're actually doing anything with the data rather than just
hammering TLS accessed with no intervening code, I think the
difference will be so small that it's borderline on not even being
statistically significant without a huge number of runs.
Rich