thread-local data access

[Ulrich Drepper <drepper at redhat dot com>]

We slowly have to think about the platforms which do not yet have
thread-local data access through anything but the POSIX API.  This
will be a problem since there are at least two changes coming up which
require fast access the thread-local data.

The situation from my perspective is as follows:

 - x86:   %gs register, fast enough
 - SPARC: dedicated thread register
 - IA-64: likewise
 - Alpha: PAL call, fast enough (according to rth)

What about the other architectures?  I guess m68k is not really that
important anymore.  More of a problem for me are Arm, MIPS, and PPC.
Also, do the people who designed the ABI for PA, SH, and S390 thought
about this?


The consequences of not having fast TLD will become quite dramatic:
those architecture will simply not support the upcoming multi-threaded
APIs (and therefore will be incompatible to the other archs) or will
be very slow (due to the hidden function calls to the POSIX API).

It is not enough to have an libc-internal ABI, it must be used
everywhere in the program.  And it should become the default since
otherwise you need multiple copies of the libc and other libs and must
not mix them.


What are people's takes on this?  This will surely be a high-end MT
API and if an arch like SH which is mainly used on small machines
isn't using it this will not mean the end of the world.  But it means
that applications written with the extended ABI in mind will not be
compilable on this architecture.


In case you have to know what extensions are currently planned:

 - TLD support in programming languages (think OpenMP)

 - MT locale model (I'm writing the specs down these days)

There will probably be more in future.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------