Messages in this thread | | | Subject | Re: 32-bit syscalls from 64-bit process on x86-64? | From | Jeremy Fitzhardinge <> | Date | Tue, 07 Dec 2004 18:30:56 -0800 |
| |
On Sat, 2004-12-04 at 15:40 +0100, Petr Vandrovec wrote: > Seems to work for me. See second example below. If it won't work, you > can always use reverse procedure to one I used in syscall.c - only > problem is that you'll have to allocate some memory below 4GB to > hold code & stack during 32bit syscall.
I've been playing with this.
If I have a 64-bit process, and I switch to the 32-bit segment with ljmp it works fine - until I get a signal. The kernel doesn't reload cs with the 64-bit segment before calling the handler, which causes an obvious mess. I've been experimenting with setting the handler to this little trampoline:
handler32: .code32 ljmp *1f .code64 1: .long handler /* x86-64 handler */ .word 0x33 /* USER_CS */
but this always gets a SIGSEGV on the ljmp. I don't know why - there are lots of reasons for getting a GPF, and there doesn't seem to be a way to distinguish them.
(Hm, if I change this to the "ljmp $0x33, $handler" form, it gets to handler, but then crashes because rsp has been truncated to 32-bits. Hmm2, OK, so if I set up a 32-bit stack and a signal stack, it all works OK.)
Any ideas? Is this a kernel bug: should it always make sure that CS has the right value before starting a signal handler? I notice that the ia32 kernel reloads cs before starting a signal handler.
J
- 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/
| |