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

Szabolcs Nagy szabolcs.nagy@arm.com
Fri Apr 24 21:27:00 GMT 2015



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.



More information about the Libc-alpha mailing list