mailing list of musl libc
 help / color / mirror / code / Atom feed
* do we need different definition of  __SYSCALL_LL_E for different endian?
@ 2019-03-15  3:52 wangjianjian (C)
  2019-03-15  8:32 ` Andre McCurdy
  0 siblings, 1 reply; 2+ messages in thread
From: wangjianjian (C) @ 2019-03-15  3:52 UTC (permalink / raw)
  To: musl

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);
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



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: do we need different definition of __SYSCALL_LL_E for different endian?
  2019-03-15  3:52 do we need different definition of __SYSCALL_LL_E for different endian? wangjianjian (C)
@ 2019-03-15  8:32 ` Andre McCurdy
  0 siblings, 0 replies; 2+ messages in thread
From: Andre McCurdy @ 2019-03-15  8:32 UTC (permalink / raw)
  To: musl

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
>


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-03-15  8:32 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-15  3:52 do we need different definition of __SYSCALL_LL_E for different endian? wangjianjian (C)
2019-03-15  8:32 ` Andre McCurdy

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).