[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 31 Aug 2017 18:52:30 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: simplification of __aeabi_read_tp
On Fri, Sep 01, 2017 at 12:26:05AM +0200, Jörg Mische wrote:
> Hi,
>
> I am trying to adapt the ARM assembler parts to ARMv6-M (the thumb2
> subset of the Cortex-M0) without breaking ARMv4T compatibility. One
> issue is the function __aeabi_read_tp(), which may not clobber any
> registers except the return value in r0.
>
> Register saving code that avoids "pop {lr}" (which is not supported
> by ARMv6-M) and "pop {pc}" (which is not supported by ARMv4T) is
> very ugly, therefore I took a closer look at its internals and
> discovered the following:
>
> __aeabi_read_tp() calls __aeabi_read_tp_c() which inlines the
> function __pthread_self(). With ARMv7 and above, __pthread_self()
> simply reads the coprocessor register c13 without clobbering any
> registers. Below ARMv7, the function pointer __a_gettp_ptr is
> called. __a_gettp_ptr either points to __a_gettp_cp15() (a routine
> that reads c13) or to the kuser_get_tls function provided by the
> kernel.
>
> The interesting point is that neither __a_gettp_cp15() (only one
> instruction and a return) nor kuser_get_tls (according to the kernel
> spec) clobber any registers. The only reason for saving the
> registers is the indirection via the C-function __aeabi_read_tp_c(),
> where the compiler is allowed to clobber r0-r3.
>
> Since inline functions cannot be called from assembler and any C
> code must be avoided, I rewrote the code of __pthread_self()
> directly in assembler in __aeabi_read_tp.S. With these modifications
> the binary code is not only faster, it also works on the Cortex-M0
> processor.
If you look at the commit text for commit
29237f7f5c09c436825a7a12b68ab4143b0ebd1f which added the indirection
through C code, one of the goals was to make the arm target
fdpic-ready (to support shareable text on cortex-m).
> diff --git a/src/thread/arm/__aeabi_read_tp.S
> b/src/thread/arm/__aeabi_read_tp.S
> new file mode 100644
> index 0000000..897b4f8
> --- /dev/null
> +++ b/src/thread/arm/__aeabi_read_tp.S
> @@ -0,0 +1,22 @@
> +.syntax unified
> +.global __a_gettp_ptr
> +.hidden __a_gettp_ptr
> +.global __aeabi_read_tp
> +.type __aeabi_read_tp,%function
> +__aeabi_read_tp:
> +
> +#if ((__ARM_ARCH_6K__ || __ARM_ARCH_6ZK__) && !__thumb__) ||
> __ARM_ARCH_7A__ || __ARM_ARCH_7R__ || __ARM_ARCH >= 7
> +
> + mrc p15,0,r0,c13,c0,3
> + bx lr
> +
> +#else
> +
> + ldr r0,2f
> + add r0,r0,pc
> + ldr r0,[r0]
> +1: bx r0
> + .align 2
> +2: .word __a_gettp_ptr-1b
> +
> +#endif
Here, __a_gettp_ptr-1b is not position-independent on fdpic, since
__a_gettp_ptr lies in the data segment and 1b lies in the text
segment, whose base addresses can float relative to one another. Of
course we could write an fdpic-specific version of the asm function to
access the hidden GOT pointer argument and do a GOT-relative load, but
the intent here was for the compiler to take care of all the ABI
issues.
OTOH, relying on the compiler not to generate code that could clobber
other normally-call-clobbered registers (the floating point ones) is
probably wrong, so maybe what I did here is just a bad idea and your
approach (with an extra special case for fdpic once it's added) is the
right way.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
