[PATCH 2/2] bfd/elfnn-aarch64.c: set DF_STATIC_TLS when emitting IE relocs

[Kyle McMartin]

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