[OE-core] pseudo: host user contamination

[Andre McCurdy]

On Sat, Mar 24, 2018 at 11:22 AM, Seebs <seebs at seebs.net> 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