Re: [Qemu-devel] [PATCH] vl.c: Implement SIGILL signal handler for triggering SIGSEGV

[Laszlo Ersek <lersek@redhat.com>]

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