Mikael Pettersson wrote:
The i386 TLS API has three components:
(1) set_thread_area(entry_number == -1):
allocates and sets up the first available TLS entry and
copies the chosen GDT index back to user-space
(2) set_thread_area(6 <= entry_number && entry_number <= 8):
allocates and sets up the indicated GDT entry
(3) get_thread_area(6 <= entry_number && entry_number <= 8):
retrieves the contents of the indicated GDT entry
Only (1) works in x86-64's ia32 emulation, the other two fail
with EINVAL because x86-64 only accepts GDT indices 12 to 14
for TLS entries. glibc only uses (1).
If you move the i386 TLS GDT entries to other indices then you
break (2) and (3) also on i386.
(2) and (3) are always OK if you pass it the result of (1) - ie to
update or readback a previously allocated descriptor. Neither is useful
without having done (1) first. The fact that 32-on-32 and 32-on-64
differ here means that nothing can (an apparently nothing does) depend
on hardcoded knowledge of the TLS descriptor indicies anyway.
It's not difficult to design a better i386 TLS API that avoids
requiring user-space to know the actual GDT indices (just use
logical TLS indices and always copy the GDT index to user-space).
but unfortunately that doesn't help us
You still need the real indicies to construct a selector to put into a
segment register - ie, actually do something useful. Changing the API
to use abstract "TLS indicies" would also require a call to return the
"TLS base", which hardly seems like an improvement.
Also, there's no inherent reason why the TLS indicies should be
contigious; it happens to be true, but there's nothing useful userspace
can do with that knowledge. Allowing them to be discontigious may be
helpful, for example, in packing the most used TLS entries (ie #1) into
a hot cache line, while putting the lesser-used ones elsewhere. The
current API could deal with this without needing to change.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
