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