[trivial] linux-user: enable sigaltstack for all architectures

There is no reason to limit sigaltstack syscall to just a few
architectures and pretend it is not implemented for others.

If some architecture is not ready for this, that architecture
should be fixed instead.

This fixes LP#1516408.

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
---
This patch depends on a previous patch I sent, "unicore32: convert
get_sp_from_cpustate from macro to inline", or else unicore32-user
wont build.
---
 linux-user/syscall.c | 6 ------
 1 file changed, 6 deletions(-)

On 29 December 2015 at 09:51, Michael Tokarev <mjt@tls.msk.ru> wrote:
> There is no reason to limit sigaltstack syscall to just a few
> architectures and pretend it is not implemented for others.
>
> If some architecture is not ready for this, that architecture
> should be fixed instead.
>
> This fixes LP#1516408.
>
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
> ---
> This patch depends on a previous patch I sent, "unicore32: convert
> get_sp_from_cpustate from macro to inline", or else unicore32-user
> wont build.
> ---
>  linux-user/syscall.c | 6 ------
>  1 file changed, 6 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 6c64ba6..3ceb3e2 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -8292,14 +8292,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
>          break;
>      }
>      case TARGET_NR_sigaltstack:
> -#if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_MIPS) || \
> -    defined(TARGET_SPARC) || defined(TARGET_PPC) || defined(TARGET_ALPHA) || \
> -    defined(TARGET_M68K) || defined(TARGET_S390X) || defined(TARGET_OPENRISC)
>          ret = do_sigaltstack(arg1, arg2, get_sp_from_cpustate((CPUArchState *)cpu_env));
>          break;
> -#else
> -        goto unimplemented;
> -#endif
>
>  #ifdef CONFIG_SENDFILE
>      case TARGET_NR_sendfile:

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

Hi Peter!

On 01/07/2016 12:52 PM, Peter Maydell wrote:
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

Has this been committed yet? I can't see the change in cgit.

Cheers,
Adrian

On 7 January 2016 at 12:14, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> Hi Peter!
>
> On 01/07/2016 12:52 PM, Peter Maydell wrote:
>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>
> Has this been committed yet? I can't see the change in cgit.

No. "Reviewed-by" means I just code reviewed it. At some point
it will be picked up by a subtree maintainer (either the
-trivial subtree or the linux-user one). That person will then
at some point send me a pull request for their subtree which
will result in the commit getting merged into master when I
apply that pull request.

thanks
-- PMM

On 01/07/2016 01:18 PM, Peter Maydell wrote:
> No. "Reviewed-by" means I just code reviewed it.

Yeah, that is clear :-).

> it will be picked up by a subtree maintainer (either the
> -trivial subtree or the linux-user one). That person will then
> at some point send me a pull request for their subtree which
> will result in the commit getting merged into master when I
> apply that pull request.

Ok, I didn't know qemu has subtrees as well as the kernel. I
thought it would be easier to send in drive-by patches as
in systemd, for example.

PS: In order to make qemu-sh4 actually usable again, it would
    be great if the setup_frame changes by Laurent Vivier [1]
    could be merged as well. Without the fix, qemu-user reproducibly
    segfaults when emulating sh4 [2].

> [1] https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04883.html
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805827