[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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 

> > 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

Reply to: