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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
