[PATCH] [BZ 18034] [AArch64] Lazy TLSDESC relocation data race fix
Alexandre Oliva
aoliva@redhat.com
Tue Jun 9 06:30:00 GMT 2015
On Apr 22, 2015, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> - I don't understand the role of the hold function in the general
> TLSDESC design
On machines that can't overwrite the entire descriptor atomically, it is
intended to stop a thread from using a partially-relocated descriptor.
Users of the descriptor must load the function word before the operand,
and the relocator must first set the function word to hold, then modify
the operand, and then set the function to its final value.
This is supposed to ensure that users of the descriptor can tell the
relocation of the descriptor is already underway, thus the operand may
already be trashed. I agree it's not extremely relevant for current
implementations, but the x86 TLSDESC RFC (the first that couldn't update
the descriptor atomically) describes other envisioned implementations
that could take advantage of it.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
More information about the Libc-alpha
mailing list