[prev in list] [next in list] [prev in thread] [next in thread] 

List:       musl
Subject:    Re: [musl] do we need different definition of __SYSCALL_LL_E for different endian?
From:       Andre McCurdy <armccurdy () gmail ! com>
Date:       2019-03-15 8:32:48
Message-ID: CAJ86T=XGHYkCba20Dy5yFeRMWaTWtM8BJtJnSP6mExYDfkbfYA () mail ! gmail ! com
[Download RAW message or body]

On Thu, Mar 14, 2019 at 9:15 PM wangjianjian (C)
<wangjianjian3@huawei.com> wrote:
> 
> This is arm definition of macro __SYSCALL_LL_E:
> #define __SYSCALL_LL_E(x) \
> 2 ((union { long long ll; long l[2]; }){ .ll = x }).l[0], \
> 3 ((union { long long ll; long l[2]; }){ .ll = x }).l[1]
> 
> But do we need to deferent definitions for different endian?
> From Linux man page,
> 
> For  example,  on the ARM architecture Embedded ABI (EABI), a 64-bit value (e.g., \
> long long) must be aligned to an even register pair.  Thus, using syscall() instead \
> of the wrapper provided by glibc, the readahead() system call would be invoked as \
> follows on the ARM architecture with the EABI: 
> syscall(SYS_readahead, fd, 0,
> (unsigned int) (offset >> 32),
> (unsigned int) (offset & 0xFFFFFFFF),
> count);

You seem to be looking at an out of date version of the man page.
Later versions have been fixed to make it clearer that the order is
endian specific:

  http://man7.org/linux/man-pages/man2/syscall.2.html

> Seems the third argument is the high 32 bit and the fourth argument is the low 32 \
> bit. So do we need below fix? #ifdef __ARM_BIG_ENDIAN
> #define __SYSCALL_LL_E(x) \
> 2 ((union { long long ll; long l[2]; }){ .ll = x }).l[0], \
> 3 ((union { long long ll; long l[2]; }){ .ll = x }).l[1]
> #else
> #define __SYSCALL_LL_E(x) \
> 2 ((union { long long ll; long l[2]; }){ .ll = x }).l[1], \
> 3 ((union { long long ll; long l[2]; }){ .ll = x }).l[0]
> #endif
> 
> Thanks.
> 
> BR,
> Wang Jianjian
> 


[prev in list] [next in list] [prev in thread] [next in thread]