qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] linux-user: Correct definition of stack_t


From: LemonBoy
Subject: Re: [PATCH] linux-user: Correct definition of stack_t
Date: Thu, 5 Nov 2020 16:48:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 05/11/20 16:16, Peter Maydell wrote:
> 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...)
> 

What an interesting coincidence, I also stumbled across this bug while
debugging a crash with some sparc64 binary.

>> 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.
> 

I'll change it and send an updated patch ASAP.

>> [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
> 



reply via email to

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