qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] qemu-pcc 2.8.0 linux-user segfaults


From: Sam Bobroff
Subject: Re: [Qemu-ppc] [Qemu-devel] qemu-pcc 2.8.0 linux-user segfaults
Date: Thu, 2 Feb 2017 10:48:23 +1100
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Feb 01, 2017 at 03:25:05PM +0000, Peter Maydell wrote:
> On 30 January 2017 at 23:52, Sam Bobroff <address@hidden> wrote:
> >> On 01/16/2017 03:56 PM, Aníbal Limón wrote:
> >> > I'm trying to upgrade qemu to 2.8.0 in Openembedded-core and segfaults
> >> > in qemu-ppc when is executing:
> 
> > I've recently encountered a similar problem and I've posted a fix. If
> > you'd like to try it, it's here:
> >
> > https://lists.gnu.org/archive/html/qemu-ppc/2017-01/msg00413.html
> 
> Hmm, I missed that patch (it doesn't seem to have made it
> to the qemu-devel list), but it isn't correct, I'm afraid.

Oh, sorry I think I forgot to cross post it!

Thanks for taking a look at it :-)

> In the patch for handling TARGET_USER_ESIGRETURN you must
> not change the nip register, because we will have just
> set it from the signal context that the guest provided
> to the sigreturn syscall. (The patch as it stands will
> cause us to reexecute an instruction after return from
> a signal handler, which isn't going to go very well).

Ah, thank you. I think I understand what you mean: do_syscall() and the
TARGET_QEMU_ESIGRETURN case must both see the same value for env->nip().

I tried a test program that went through that case (which I obviously
should have done before) and you're definitely right, because userspace
gets stuck looping on the system call. Removing the NIP adjustment from
the case seems to fix it. Is that what you mean? (I'll post a v2 with
that change if so.)

It seems that the similar adjustment for the TARGET_ERESTARTSYS should
stay, as removing it causes signal restart to fail (userspace sees
-EINTR even when they've specified a signal handler with SA_RESTART).

> David, can you drop that patch from your ppc queue, please?
>
> (I think the change is good otherwise but I couldn't
> seem to find the bit in the ppc linux kernel that
> corresponds to moving the NIP value around.)

> thanks
> -- PMM

Thanks again for the help!
Sam.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]