[OE-core] pseudo: host user contamination

[Andre McCurdy]

On Mon, Mar 26, 2018 at 7:07 PM, Seebs <seebs at seebs.net> wrote:
>
>>> I remain interested in why the glibc implementation does all these
>>> weird things on some architectures if none of those things matter.
>>
>> Which glibc implementation? I'll take a look.
>
> syscall(2) for various architectures, which is actually implementing
> all this fancy ABI stuff. If that doesn't matter, why's it there?

The syscall manpage is from the kernel manpages, not glibc.

  http://man7.org/linux/man-pages/man2/syscall.2.html

I agree it's a bit weird that it contains a description of the
kernel's syscall calling conventions, but perhaps that's a historical
leftover from an original document which described kernel internals?
Either way I think it's useful background information.

> I think we may be talking past each other.

Well, the good news is I'm almost done talking :-)

> I'm not looking for "I tried
> this once on one architecture and it worked." I'm looking for a good
> enough understanding of *why* all these things are in the man page, and
> when they might matter, that I can reasonably predict whether this will
> work on lots of other platforms, and continue to work in the future.

I'm not sure I can help you with your understanding.

Personally, I've read the manpage, I've read code in glibc and musl,
I've straced coreutils mv and various little test programs on 32bit
ARM plus 32bit and 64bit x86 and written a wrapper for libc syscall()
which either intercepts or passes through syscalls. Everything I've
found seems to be consistent to the point that I've satisfied myself
that I have a pretty clear understanding of how libc syscall() works,
including why ARM EABI sometimes needs an extra argument to offset
64bit values - and when it matters for a wrapper and when it doesn't.
I don't think there's much more I can do.