Jamie Lokier <ja...@shareable.org> writes: > Markus Armbruster wrote: >> Paolo Bonzini <pbonz...@redhat.com> writes: >> >> > On 03/15/2010 07:36 PM, Markus Armbruster wrote: >> >> Please don't tell me that user emulators make abort() return. abort() >> >> is declared __noreturn__, and the optimizer may well rely on that. >> > >> > If the user programs make a "signal (SIGABRT, SIG_IGN)" call, I >> > suppose abort() will return. >> >> I program doing that gets what it asks for, and richly deserves. > > 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.
I'd expect such handler not to return, but SIG_DFL, clean up, then re-raise the signal. Regardless, a guest program can do whatever it pleases, and that includes the stupid as well as the clever. But the guest's doings should never unduly interfere with QEMU's use of signals. > 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. Agreed. The guest replacing one of QEMU's handlers with SIG_IGN or SIG_DFL would be "fun", too. No idea whether that's actually possible; I know next to nothing about user mode emulation.
