On Mon, 3 Dec 2007, Roman Zippel wrote:
The helper __kernel_read_tp returns the thread pointer in register a0
(not d0) and may clobber other call-clobbered registers. (Because it
is only called from __m68k_read_tp, which is called through the PLT,
and the resolver may clobber call-clobbered registers, there seems to
be no advantage in restricting clobbers from this helper.)
Why is there a need for separate __kernel_read_tp/__m68k_read_tp? Wouldn't
this add one unneccessary indirection? Couldn't one of them just be an
alias for the other?
Personally I'd call them ..._get_tp/_set_tp (i.e. closer to what ARM is
using).
__kernel_read_tp is a symbol defined in the vDSO, the glibc resolver needs
to resolve it shortly after startup and store the function pointer in a
variable in glibc. Applications do not know the address of the vDSO or
how to resolve symbols in it - __kernel_read_tp is not a symbol visible
when compiler-generated code is linked, so the compiler cannot generate
calls to it; instead it generates calls to __m68k_read_tp, which is
defined in libc.
There remains the possibility in future of getting rid of the indirection
overhead by arranging for the PLT entry for __m68k_read_tp to call the
vDSO function directly, as discussed in the thread
<http://sourceware.org/ml/libc-alpha/2005-03/msg00189.html>.
The ARM function defined by the ARM EABI, to which the compiler generates
calls, is called __aeabi_read_tp.
The helper __kernel_write_tp sets the thread pointer to the value in
a0. It does not clobber any registers other than the condition codes.
This function is not really critical, so I'd keep clobber rules in line
with above.
It might need to end up as a syscall (as used on ARM), given that it's not
critical and it may be required too early in startup for the vDSO to be
usable.
The same issue as for GOT accesses also applies to accesses to TLS
data using the local dynamic and local exec models. The example code
sequences determine the address of the variable, but typically it will
be desired to read or write the variable and this may be done more
efficiently using offset addressing. It is proposed that by default
the compiler will require the relevant TLS area to be accessible using
16-bit offsets, and that an option -mxtls must be used when compiling
objects that use the local dynamic or local exec models and will be
linked into a module with too large a TLS area for 16-bit offset
addressing.
Trying to use 16bit offset has advantages for m68k too, as the extra 16bit
makes the instruction by 32bit larger.
However I don't have a good feeling at forcing a specific model at the
ABI level, I'd rather leave the default to the system environment and
create two options to specifically select the model (e.g. FRV has
-mtls/mTLS).
The proposal here is really a proposal for what will be done in the
compiler implementation (default 16-bit, -mxtls to enable 32-bit) rather
than an an ABI-level one; the ABI defines the 8-bit, 16-bit and 32-bit
relocations for everything, and the compiler chooses which to use based on
the options given; whether the result links depends on whether the
relocations chosen are suitable to the amount of data being addressed.
--
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
