On Wed, Feb 01, 2017 at 03:25:05PM +0000, Peter Maydell wrote: > On 30 January 2017 at 23:52, Sam Bobroff <sam.bobr...@au1.ibm.com> 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.
