Re: Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2
Hi,
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: