On Monday 01 April 2013 05:30:06 Michael Kerrisk (man-pages) wrote: > On Mon, Apr 1, 2013 at 10:37 AM, Mike Frysinger <vapier@xxxxxxxxxx> wrote: > > On Monday 01 April 2013 03:19:43 Mike Frysinger wrote: > >> 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. > > > > in random grepping of code bases (uClibc), i believe the xtensa arch also > > does 64bit register pair aligning. a cursory scan of the kernel seems > > to back this up. > > Also SuperH? i don't think so ... the pread/pwrite is indeed funky for SuperH, but i'm pretty sure that's a wart they accidentally copied from another arch (ppc maybe?) when they implemented the syscall rather than needing to do 64bit register alignment. i say that because qemu/strace/glibc don't do the register realigning for any other function. > For my own education: which part of the kernel sources backed this up? for xtensa, this part: arch/xtensa/include/uapi/asm/unistd.h: __SYSCALL(260, sys_readahead, 5) that says readahead takes 5 args, but that's only true for 32bit arches if you're re-aligning the value. the other 64bit syscalls have the same property (+1 to the normal # of args). additionally, the arch/xtensa/kernel/syscall.c file has a custom fadvise64_64 syscall with re-order arguments (with "advice" moved from last to 2nd) so that the shifting of args doesn't end up requiring 7 slots (ala mips/o32). -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
