On Sat, Mar 24, 2018 at 11:22 AM, Seebs <[email protected]> wrote: > > Every other function we wrap *has* a meaningful prototype, with > arguments in a knowable order. But look at the EABI example; if we want > to actually *process* renameat2(), it's not enough to pass arguments on > blindly, we have to be sure we know exactly which arguments are which. > If the pointers can be 64-bit pointers, though, that may mean that > we have to expect the incoming arguments to be (olddirfd, 0, oldpathhi, > oldpathlo, newdirfd, 0, newpathhi, newpathlo, flags), but only on some > architectures, where others would use (olddirfd, oldpath, newdirfd, > newpath, flags).
The EABI example applies to 64bit values on 32bit architectures. Since pointers are 32bit values on 32bit architectures the example doesn't apply to renameat2 (which only passes int's and pointers - nothing which would be a 64bit value on a 32bit architecture). ie there is never any "oldpathhi, oldpathlo", only "oldpath", etc. If there _were_ some architecture dependent ordering of the renameat2 arguments passed into the syscall() ABI then it would have to be reflected in the code which originally calls syscall(), e.g. the code in gnulib. http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/renameat2.c;h=a295ec33f33dfe14e1d29cfae5d2c36e82d01ef4;hb=HEAD#l74 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
