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 from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
