On 09/05/13 15:26, Paolo Bonzini wrote: > Il 05/09/2013 14:19, Michal Novotny ha scritto: >> This is the patch to introduce SIGILL handler to be able to trigger >> SIGSEGV signal in qemu. This has been written to help debugging >> state when qemu crashes by SIGSEGV as a simple reproducer to >> emulate such situation in case of need. > > What's wrong with "kill -11" or, within gdb, "j *0x1234"? Why do you > need a SIGILL handler for this? In fact, SIGILL is a pretty bad choice: > QEMU includes a JIT compiler, so a SIGILL is a relatively common thing > to happen while debugging it. > > Also: > > (1) there is a known bug in qemu-thread-posix.c, which should not block > SIGILL, SIGBUS, SIGSEGV, SIGFPE and SIGSYS. Without fixing that, this > trick will only work for the iothread and not for the VCPU threads. If > you can produce a patch for this, it would be very nice. > >> >> + int *p = NULL; >> + >> + *p = 0xDEADBEEF; > > (2) This is undefined behavior. You probably want something like > "volatile int *p = (volatile int *)(intptr_t)4;" instead.
What's wrong with raise(SIGSEGV)? I don't understand the motivation BTW -- what sense does it make to turn SIGILL into SIGSEGV? If someone just wants to force a "coredump due to signal" interactively, SIGQUIT was invented *exactly* for that. You can even send it from the controlling terminal directly, with Ctrl-\. (More precisely, by entering QUIT character, see eg. the stty manual.) (Also, in this specific case it would be no problem if all but one threads blocked SIGQUIT -- the terminal driver or the "kill" utility would generate the signal for the entire process, not a specific thread, and then the signal would be delivered to some thread among those threads that are not blocking the signal.) Laszlo
