Re: Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2
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@codesourcery.com
Reply to: