[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