Re: 32-bit syscalls from 64-bit process on x86-64?

[Jeremy Fitzhardinge <jeremy@goop.org>]

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