[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] linux-user: Correct definition of stack_t
From: |
Peter Maydell |
Subject: |
Re: [PATCH] linux-user: Correct definition of stack_t |
Date: |
Thu, 5 Nov 2020 15:16:02 +0000 |
On Thu, 5 Nov 2020 at 14:55, LemonBoy <thatlemon@gmail.com> wrote:
>
> From 914c30863b45d6fcd3e2fc83929bcac546be1555 Mon Sep 17 00:00:00 2001
> From: LemonBoy <thatlemon@gmail.com>
> Date: Thu, 5 Nov 2020 15:48:24 +0100
> Subject: [PATCH] linux-user: Correct definition of stack_t
>
> Some platforms used the wrong definition of stack_t where the flags and
> size fields were swapped or where the flags field had type ulong instead
> of int.
Coincidentally, I just noticed this yesterday (am in the middle of
trying to debug why qemu-sparc64 crashes trying to start bash...)
> Due to the presence of padding space in the structure and the prevalence
> of little-endian machines this problem went unnoticed for a long time.
>
> The type definitions have been cross-checked with the ones defined in
> the Linux kernel v5.9, plus some older versions for a few architecture
> that have been removed and Xilinx's kernel fork for NiosII [1].
>
> The microblaze header and the bsd-user ones remain unchanged as I don't
> know if they are wrong or not.
As far as I can tell, Microblaze doesn't define its own stack_t,
so it must be using the asm-generic one, so I think it also needs
changing.
> [1]
> https://github.com/Xilinx/linux-xlnx/blob/master/arch/nios2/include/uapi/asm/signal.h
> Signed-off-by: Giuseppe Musacchio <thatlemon@gmail.com>
Other than also changing microblaze,
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
thanks
-- PMM