On 03/16/2010 06:55 PM, Jamie Lokier wrote:
A guest program is also allowed to trap SIGABRT with a signal handler,
and that does have some uses. E.g. cleaning up temporary files and
shmem segments following a crash when calling 3rd party code.
Whatever the guest does with SIGABRT, it should not result in_QEMU_
crashing - whether due to abort() returning, or QEMU's control flow
jumping to the guest's signal handler from an unexpected location.
That's very hard to ensure however if QEMU was already in unstable
state, as witnessed by its call to abort(). Things can only go downhill.
Maybe there should be a qemu_abort wrapper (and a QEMU_ASSERT companion)
that does simply abort/assert under system emulation, but under
user-mode emulation does
signal (SIGABRT, SIG_DFL);
abort ();
Paolo
