On 3/19/10, Jamie Lokier 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 case coul
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
> 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 signa
Jamie Lokier writes:
> Markus Armbruster wrote:
>> Paolo Bonzini 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 th
On 3/17/10, Paolo Bonzini 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 party code.
> >
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
Jamie Lokier 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 (SIGABRT, SI
Markus Armbruster wrote:
> Paolo Bonzini 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 (
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
> abo
Paolo Bonzini 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 ab
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
On 3/15/10, Paolo Bonzini 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);
> > >
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) {
Paolo Bonzini 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.
>
On 3/15/10, Paolo Bonzini 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 c
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 consid
16 matches
Mail list logo
