[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, Joseph S. Myers wrote:

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

Ok, thanks for the pointer. When I played with it I used a dummy .so to 
get the symbols, I thought glibc would use a weak symbol or something like 
this to export it to the applications.

> The ARM function defined by the ARM EABI, to which the compiler generates 
> calls, is called __aeabi_read_tp.

The kernel part uses set_tls/get_tls.

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

Even for early startup I don't see that it would need all registers, so 
that a consistent calling convention is IMO more important.

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

That doesn't change my point - the used model should IMO be defined by the 
system environment and the compiler should provide the explicit option to 
choose either model.

bye, Roman

Reply to: