Messages in this thread | | | Date | Wed, 13 Sep 2006 23:23:18 -0400 | From | "Albert Cahalan" <> | Subject | Re: Assignment of GDT entries |
| |
Linus Torvalds writes: > On Wed, 13 Sep 2006, Jeremy Fitzhardinge wrote:
>> So does this mean that moving the user-visible cs/ds isn't >> likely to break stuff, if it has been done before? > > Yes. I _think_ we could do it. It's been done before, and nobody noticed. > > That said, it may actually be that programs have since become much more > aware of segments, for a rather perverse reason: the TLS stuff. Old > programs are all very much coded and compiled for a totally flat model, > and as such they really don't know _anything_ about segments. But with > more TLS stuff, it's possible that a modern threded program is at least > aware of _some_ of it.
We actually have an ABI problem right now because of this. Note that i386 and x86_64 use different GDT slots.
As far as I can tell, users need to hard-code the mapping from TLS slot to segment number. They use 0,1,2 to ask the kernel to set things up (via set_thread_area), but can't just pop that into %fs or %gs.
So a 32-bit app using set_thread_area can work on i386 or x86_64, but not both. I guess glibc gets %gs set up free via clone() with the right flags, and thus does not need to determine the kernel. For anything involving set_thread_area though, it gets nasty.
Typical hacks that result from this:
call uname() and look for "x86_64" see of the addresses of local variables exceed 0xbfffffff examine /proc/1/maps check for a /lib64 directory change SSE register 8 in a signal handler frame and see if it sticks checksum the vdso code ...
Please save us from these foul hacks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |