Re: [PATCH][BZ #17078] ARM: R_ARM_TLS_DESC prelinker support

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Tue, 1 Jul 2014, Rich Felker wrote:

> >  Here is a change to the dynamic linker to add prelinker support for the 
> > R_ARM_TLS_DESC relocation.  Two cases can be considered here, the usual 
> > one where lazy binding is in use and the less frequent one, where 
> > immediate binding is requested via the use of the DF_BIND_NOW dynamic flag 
> > (e.g. by using the GNU linker's "-z now" option).
> > 
> >  The change below only handle the first case.  In this scenario the 
> 
> Given that there seems to be an intent for glibc to move towards safe
> allocation of TLS at dlopen/pthread_create time rather than lazy
> allocation (which inherently leads to crashing under memory
> exhaustion), I don't think it's useful to focus on the lazy case,
> which also crashes if there's no memory for the tls index structure.
> Rather the lazy case should eventually be removed.
> 
> Technically it's possible to support the lazy case without crashing on
> memory exhaustion, by simply re-doing the lookup every time the symbol
> is referenced if allocation fails. But I really doubt anybody wants to
> implement that hideously-slow fallback. And the allocation also makes
> the accesses async-signal-unsafe, which is another bug that should be
> fixed.

 Thank you for your input.  I think it is good that you think about glibc 
improvements, and you are welcome to submit patches to back up your 
considerations.

 However this change handles what is already there and supported across 
the toolchain and glibc, fixing a legitimate use case that does not work 
although it should.  It is also mostly agnostic about dynamic loading 
implementation internals by merely copying data from the DT_TLSDESC_PLT 
dynamic tag to the memory location pointed by the DT_TLSDESC_GOT tag as 
per the TLS descriptor ARM/Linux psABI addendum.  Any change to this 
semantics that your suggested improvements may require will be an 
incompatible ABI change and support for preexisting binaries will have to 
be retained anyway.  There is also GOT[1] initialised here as per our 
practice elsewhere, which is our dynamic linker's internal protocol, and 
obviously any incompatible change of yours will have to address the 
different treatment of GOT[1] throughout our code anyway.  But at the 
point you'll have redefined or removed DT_TLSDESC_PLT/DT_TLSDESC_GOT this 
is going to be the least of a problem.

 Therefore I fail to see how the observations you have made relate to the 
bug fix I have proposed; as I say you're free to submit any improvements 
on top of it.

  Maciej