This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 2/2] bfd/elfnn-aarch64.c: set DF_STATIC_TLS when emitting IE relocs
- From: Kyle McMartin <kmcmarti at redhat dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at arm dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, "will dot newton at linaro dot org" <will dot newton at linaro dot org>, "nickc at redhat dot com" <nickc at redhat dot com>
- Date: Tue, 1 Jul 2014 12:19:44 -0400
- Subject: Re: [PATCH 2/2] bfd/elfnn-aarch64.c: set DF_STATIC_TLS when emitting IE relocs
- Authentication-results: sourceware.org; auth=none
- References: <20140701001808 dot GB9511 at redacted dot bos dot redhat dot com> <53B27938 dot 3040203 at arm dot com> <20140701141428 dot GD9511 at redacted dot bos dot redhat dot com> <20140701154205 dot GE4471 at bubble dot grove dot modra dot org>
On Wed, Jul 02, 2014 at 01:12:05AM +0930, Alan Modra wrote:
> On Tue, Jul 01, 2014 at 10:14:28AM -0400, Kyle McMartin wrote:
> > it seems to be about half and half who tests what:
> > i386, x86_64, ppc all set if !info->executable
> > sparc, mips, alpha all set if info->shared
>
> DF_STATIC_TLS is a flag that says the object is using thread pointer
> relative addressing of TLS. ie. the thread local storage for that
> object must be laid out at program startup, which means the object
> can't be dlopen'd (*). So DF_STATIC_TLS is a flag for objects that
> might be dlopen'd. Hmm, and since we can actually dlopen any ET_DYN
> including PIEs it would seem that info->shared is the correct test.
>
Indeed... the specific problem I'm trying to solve is to have an easy
way to know a priori whether any static TLS relocs are present, so that
libc can choose to do the right thing for all cases. The problem right
now is, as it stands, glibc will allocate static TLS to optimize TLS
descriptor accesses, which consumes all the "reserved" static TLS space
for dlopen-ing TP relative libraries, which means any attempt to dlopen
a library which actually needs space fails. If we have this flag set,
then I can know if the link map comes from dlopen'd library (always use
dynamic TLS desc unless DF_STATIC_TLS is present) or if it was known at
ld time, in which case we have reserved space anyway. (And I can then do
it without two passes through the dyn relocs.)
I'm happy changing this, and testing changing it for places where it's
predicated on !info->executable as well, if you'd like. Mostly I just
want this to be consistent across platforms.
(I'm working on some other cleanups for the relaxation code too, but
that's a side issue.)
> *) Except that glibc allocates some extra thread local storage,
> and therefore can dynamically load shared libraries with static tls.
>
regards, Kyle