Re: [Qemu-devel] [PATCH 0/6] linux-user: safe_syscall updates

[Riku Voipio <riku.voipio@iki.fi>]

On Mon, Jun 13, 2016 at 11:09:17PM +0100, Peter Maydell wrote:
> On 13 June 2016 at 22:53, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 13 June 2016 at 22:45, Richard Henderson <rth@twiddle.net> wrote:
> >> Richard Henderson (6):
> >>   linux-user: fix x86_64 safe_syscall
> >>   linux-user: Provide safe_syscall for i386
> >>   linux-user: Provide safe_syscall for arm
> >>   linux-user: Provide safe_syscall for aarch64
> >>   linux-user: Provide safe_syscall for s390x
> >>   linux-user: Provide safe_syscall for ppc64
> >
> > I just spent today writing these for i386, arm and aarch64,
> > so we've duplicated work here :-(

On the positive side, duplication makes it easier to give
a really throughout review :)

> Also, I have a patchset which moves from the generic/hostdep.h
> to having explicitly one hostdep.h per supported architecture.
> That needs to go in before these, otherwise these break
> compilation unless you do a 'make clean'.
> 
> I'll send that out tomorrow, working version in
>  https://git.linaro.org/people/peter.maydell/qemu-arm.git/shortlog/refs/heads/sigrace-fixes

I've merged all pending patches except the safe_syscall ones to:

https://git.linaro.org/people/riku.voipio/qemu.git/shortlog/refs/heads/linux-user-for-upstream

Peter, Richard, do you have an agreement who's versions of
the safe_syscall patches should be included? 

Riku

> We also have a bug in the signal.c code which I noticed
> trying to test my i386 safe_syscall: we call sigfillset()
> on the uc_sigmask field of the ucontext_t* that the
> kernel passes us as argument 3 of the signal handler.
> This trashes a lot of stuff on the stack because the
> libc headers say "sigset_t is 128 bytes" and the kernel
> says "it's only 8 bytes", so the sigfillset() writes -1
> to a lot of the stack that it shouldn't. (I don't know
> why glibc exposes a struct that isn't actually what
> the kernel provides here, but it's a very long standing
> confusion :-( )
> 
> thanks
> -- PMM