qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] linux-user: Fix wrong use of stat instead of st


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH] linux-user: Fix wrong use of stat instead of stat64 for sparc64
Date: Thu, 19 Sep 2013 19:31:51 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8

Am 06.09.2013 19:24, schrieb Stefan Weil:
> Am 06.09.2013 19:16, schrieb Peter Maydell:
>> On 6 September 2013 17:46, Stefan Weil <address@hidden> wrote:
>>> This test case is fixed now:
>>> sparc64-linux-user/qemu-sparc64 /usr/gnemul/qemu-sparc64/busybox ls -l 
>>> block.c
>>>
>>> Signed-off-by: Stefan Weil <address@hidden>
>>> ---
>>>  linux-user/syscall.c |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>>> index ecead51..e498a92 100644
>>> --- a/linux-user/syscall.c
>>> +++ b/linux-user/syscall.c
>>> @@ -4764,7 +4764,7 @@ static inline abi_long host_to_target_stat64(void 
>>> *cpu_env,
>>>      } else
>>>  #endif
>>>      {
>>> -#if TARGET_ABI_BITS == 64 && !defined(TARGET_ALPHA)
>>> +#if TARGET_ABI_BITS == 64 && !defined(TARGET_ALPHA) && 
>>> !defined(TARGET_SPARC64)
>>>          struct target_stat *target_st;
>>>  #else
>>>          struct target_stat64 *target_st;
>> So this condition is trying to identify the platforms
>> which don't actually have a struct stat64 (which is
>> some but not all of the 64 bit platforms). I think that
>> rather than trying to enumerate those here it would
>> be better if in the sections of syscall_defs.h which
>> define target_stat/target_stat64 we had those sections
>> which don't have a target_stat64 definition instead
>> #define TARGET_NO_STRUCT_STAT64
>> and then used that here.
>>
>> -- PMM
> I even thought about a totally different solution:
>
> Could we write some sample code with all those structs
> and system calls, compile it once for each target, and
> get all information we need from the resulting binaries
> (using tools like pahole, for example)?
>
> For the moment, I think my patch is sufficient (it is also
> needed for QEMU 1.6!).
>
> Stefan


Ping? Are there any more opinions how qemu-sparc64 should be fixed?
Should we choose Peter's approach (which is good, but with a
higher risk than my patch)?

Stefan




reply via email to

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