On Monday 01 April 2013 02:22:45 Michael Kerrisk (man-pages) wrote: > On Mon, Apr 1, 2013 at 8:13 AM, Mike Frysinger wrote: > > On Monday 01 April 2013 01:33:49 Changhee Han wrote: > >> +However, when using > >> +.BR syscall () > >> +to make a system call, > >> +the caller may need to handle architecture-dependent details. > >> +For example, on ARM architecture, a > >> +.I "long long" > >> +argument is considered to be 8-byte aligned and to be split into two > >> 4-byte arguments. + > >> +.BR readahead () > >> +system call could be called like below in ARM architecture. > > > > this has nothing to do with alignment. syscalls pass args via registers, > > and in the 32bit ARM port, registers are 32bits wide. so in order to > > pass a 64bit value, you have to manually split it up. > > So, I'm not familiar with all the details here. What is the purpose of > the '0' argument that precedes 'offset' then? ok, so the answer is more nuanced, and the reasoning above is incorrect (or at the very least, poorly phrased). for ARM OABI, there is no such padding, and the proposed example is wrong and will not work. for ARM EABI, the ABI requires that 64bit values be passed in register pairs. since the kernel people wanted to avoid an assembly trampoline to unpack the 64bit value with EABI, you have to call it as proposed: syscall(readahead, fd, _pad, high32, low32) for MIPS, only the O32 ABI has this behavior. for PPC, only the 32bit ABI has this behavior. otherwise, i don't believe anyone else does this -- they just pass things along in registers w/out padding. since the current list of syscalls which are impacted is small, it might be useful to explicitly enumerate them. they are: fadvise64_64 ftruncate64 pread64 pwrite64 readahead truncate64 -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
