On 23 févr. 07, at 23:56, Ilya Shar wrote:
Sure. At first I was hitting unsupported mach
syscalls, so I modified darwin-user/syscall.h
according to
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/mach/syscall_sw.h
:
$ diff syscall.c syscall.c.orig
458,465d457
< case -33:
< DPRINTF("semaphore_signal_trap(0x%x)\n",
arg1);
< ret = semaphore_signal_trap(arg1);
< break;
< case -34:
< DPRINTF("semaphore_signal_all_trap(0x%x)\n",
arg1);
< ret = semaphore_signal_all_trap(arg1);
< break;
471,474d462
< case -37:
< DPRINTF("semaphore_wait_signal_trap(0x%x,
0x%x)\n", arg1, arg2);
< ret = semaphore_wait_signal_trap(arg1,arg2);
< break;
cvs diff -u would be easier to read for me. (or diff -u). You could
send this patch to the qemu-devel, that would be cool.
With this Sfari went past the unsupported call -33 and
now stops in call -61 (syscall_thread_switch). Can I
just modify syscalls.c in a similar way to fix it?
Yes you can!
But a really alarming thing happens before it gets
there. If my ethernet cable is not plugged in,
cmpxchg8b write to a nonwritable page brings my system
down. I suppose it happens in somewhere in the
drivers.
Ouch! I have noticed the same: qemu can trigger bugs really easily at
the kernel level :( Could you explain how you know that cmpxchg8b is
the key to our problem? Also qemu signal handlers might be overridden
by some mach calls, that could explain the problem you are
encountering. We need to work on this.
Pierre.
_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
