Jeremy Fitzhardinge writes:
Zachary Amsden wrote:
I believe 9,10,11 are reserved for future users like yourself or
expanded TLS segments. I think a bank of 3 TLS segments in the
GDT is working fine now (does NPTL even use more than one?).
Nope. And there's a comment that wine uses one more. I think
the third is completely unused.
I use the third. The sucky thing is that I need to determine if
the kernel is 64-bit to know what I must load into the segment
register. Fortunately this code is not yet out in the wild, so
you can still fix the ABI situation for me at least.
Otherwise line 1 would be ideal for putting 3 TLS, kernel+user
code+data and PDA into, thereby making 99.999% of GDT descriptor
uses come from one cache line.
That change is visible to userspace, unfortunately.
Don't think it matters much. 32-bit processes on x86-64 seem
perfectly happy with the TLS being in a different place.
Heh. I wish. Well, OK, but only because I detect the kernel!
I think the ABI is defined in terms of "use the selector for
the entry that set_thread_area/clone returns", and so is not
a constant. But I agree it would be better not to.
Hm, moving user cs/ds would be pretty visible too... Hm, and
it would have a greater chance of breaking stuff if they changed,
compared to moving the TLS...
I think that would be a lower chance, not a greater chance.
Reasons why an app might care:
a. identify a 64-bit kernel
b. far jumps between 32-bit and 64-bit code
c. reload of ds/es after a string operation on thread-private data
Perhaps i386 should change to match x86_64.
-
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]
