[PATCH] [BZ 18034] [AArch64] Lazy TLSDESC relocation data race fix

[Rich Felker]

On Fri, Apr 24, 2015 at 10:27:36PM +0100, Szabolcs Nagy wrote:
> 
> On 24/04/15 18:40, Torvald Riegel wrote:
> > On Fri, 2015-04-24 at 12:05 +0100, Szabolcs Nagy wrote:
> >>
> >> On 23/04/15 22:46, Torvald Riegel wrote:
> >>> On Wed, 2015-04-22 at 18:14 +0100, Szabolcs Nagy wrote:
> >>>> (the particular case i'm trying to fix is hard because
> >>>> the access to td->entry is generated by the compiler, so
> >>>> it has to be worked around inside the entry function.
> >>>> i think x86 does not have this issue)
> >>>
> >>> Do you mean that you want to affect the compiler-generated code after it
> >>> has been generated?
> >>
> >> i'm fixing the tlsdesc entry functions in libc
> > 
> > Sorry, I'm still not sure I can follow.  IIUC, the compiler-generated
> > asm code for TLS accesses may lack acquire barriers in some cases.  Do
> > you want to work around that by trying to adapt the glibc
> > implementation, or do you just want to fix all glibc-specific bugs, and
> > handle the compiler-side issues separately?
> > 
> 
> the compiler generated code dont need any change
> (that would break the arm and aarch64 abi)
> 
> i'm fixing the issue in the libc tlsdesc entry functions
> (because glibc is broken currently, very easy to make it
> crash)
> 
> the fix relies on the arm memory model
> 
> the real bug is the complexity of the dynamic linker code in glibc
> and the design document that specified lazy binding for tlsdesc
> without considering weak memory model issues, for these there is
> an easy fix but you won't like it: don't do lazy binding.

Being that lazy tlsdesc binding seems to break AS-safety too, and
breaks fail-safety (there's an allocation that can fail at resolving
time) I think it should just be dropped. Then this whole issue goes
away and doesn't need complex arch-specific solutions.

Rich