M.Drochner@fz-juelich.de said:
> Now I've found the following: the context returned by getcontext() is
> wrong - the ds is set to 0x3f (should be 0x17)

This looks somehow mysterious... Now that I've understood what
happens here I can explain:
It is not getcontext() which is in error here - the process
has a ds=0x3f at this point indeed. The OSYSCALL code gets
this correctly. Selector 0x3f is LUDATA32_SEL, which is technically
absolutely equivalent to LUDATA_SEL (all attribute bits are ignored
in 64-bit mode), so noone notices it.
Except setcontext(), which does a sanity check.

How does a 64-bit process get ds=LUDATA32_SEL? The culprit is
the return path of the new syscall: it does not restore ds.
(actually, it isn't saved on entry either)
If the 64-bit process gets suspended within the (new-style) syscall
and a 32-bit process gets onto the CPU in the meantime, the ds of
the 32-bit process is there and remains there.
And since I'm running 2 instances of the netbsd-i386-1.3-aout setiathome
client on my box, which are always runnable, I reproducibly got
the 0x3f selector loaded.

The appended patch fixes this for me. This is more a quick hack --
I'm not sure r10 can be overwritten here (someone explain me what
a "static chain pointer is?), and this all can be done more clever
anyway. And setcontext() needs more work anyway, see my other mail.

best regards
Matthias