fix __aeabi_read_tp oversight in arm atomics/tls overhaul
authorRich Felker <dalias@aerifal.cx>
Sat, 22 Nov 2014 17:26:38 +0000 (12:26 -0500)
committerRich Felker <dalias@aerifal.cx>
Sat, 22 Nov 2014 17:26:38 +0000 (12:26 -0500)
commit8cd0b11eafeaaec3df5113cb39094e5456ca6b22
tree310e944d94172757e21a27734d4261ee1e6d8cea
parent4a241f14a6bea81b9b50edda09f8184e35a75860
fix __aeabi_read_tp oversight in arm atomics/tls overhaul

calls to __aeabi_read_tp may be generated by the compiler to access
TLS on pre-v6 targets. previously, this function was hard-coded to
call the kuser helper, which would crash on kernels with kuser helper
removed.

to fix the problem most efficiently, the definition of __aeabi_read_tp
is moved so that it's an alias for the new __a_gettp. however, on v7+
targets, code to initialize the runtime choice of thread-pointer
loading code is not even compiled, meaning that defining
__aeabi_read_tp would have caused an immediate crash due to using the
default implementation of __a_gettp with a HCF instruction.

fortunately there is an elegant solution which reduces overall code
size: putting the native thread-pointer loading instruction in the
default code path for __a_gettp, so that separate default/native code
paths are not needed. this function should never be called before
__set_thread_area anyway, and if it is called early on pre-v6
hardware, the old behavior (crashing) is maintained.

ideally __aeabi_read_tp would not be called at all on v7+ targets
anyway -- in fact, prior to the overhaul, the same problem existed,
but it was never caught by users building for v7+ with kuser disabled.
however, it's possible for calls to __aeabi_read_tp to end up in a v7+
binary if some of the object files were built for pre-v7 targets, e.g.
in the case of static libraries that were built separately, so this
case needs to be handled.
arch/arm/src/__set_thread_area.c
arch/arm/src/arm/atomics.s
src/thread/arm/tls.s [deleted file]