On 3/19/10, Jamie Lokier ja...@shareable.org wrote:
Blue Swirl wrote:
But what if in addition to
this, the user process forked and the other process ptraced the QEMU
process,
How good is the cross-arch ptrace() emulation, anyway? :-)
Probably as good as SIGABRT abuse support. But the
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
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.
No, the guest program cannot replace QEMU's handlers; the host OS always
sees host_signal_handler for all signals.
Blue Swirl wrote:
But what if in addition to
this, the user process forked and the other process ptraced the QEMU
process,
How good is the cross-arch ptrace() emulation, anyway? :-)
-- Jamie
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
On 3/17/10, Paolo Bonzini pbonz...@redhat.com wrote:
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
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.
Paolo
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
Paolo Bonzini wrote:
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
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
Jamie Lokier ja...@shareable.org writes:
Paolo Bonzini wrote:
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
I sympathize with the general idea, but I don't like dead code
after abort(). What about cleaning that up?
Good idea, but it should be a separate patch. This patch is safe,
whereas the cleanup patch could cause problems if it's not done
carefully.
This patch is safe, however I'd consider
On 3/15/10, Paolo Bonzini pbonz...@redhat.com wrote:
I sympathize with the general idea, but I don't like dead code
after abort(). What about cleaning that up?
Good idea, but it should be a separate patch. This patch is safe,
whereas the cleanup patch could cause
Paolo Bonzini pbonz...@redhat.com writes:
I sympathize with the general idea, but I don't like dead code
after abort(). What about cleaning that up?
Good idea, but it should be a separate patch. This patch is safe,
whereas the cleanup patch could cause problems if it's not done
carefully.
I'd consider not changing assert(0)-abort()
if there is code after the assert that looks like an attempt at recovering.
Example:
if (!p) {
printf (the impossible has happened!);
assert (0);
}
return p-q;
should be changed to abort, while
if (!p) {
On 3/15/10, Paolo Bonzini pbonz...@redhat.com wrote:
I'd consider not changing assert(0)-abort()
if there is code after the assert that looks like an attempt at
recovering.
Example:
if (!p) {
printf (the impossible has happened!);
assert (0);
}
16 matches
Mail list logo
