Re: syscall(2)

On 07 Mar 2017 22:51, Victor Khimenko wrote:

On Tue, Mar 7, 2017 at 1:05 PM, walter harms [off-list ref] wrote:

quoted

Am 06.03.2017 20:08, schrieb Mike Frysinger:

quoted

On 06 Mar 2017 12:01, Michael Kerrisk (man-pages) wrote:

quoted

[Extending the CC for some other input. Changhee Han added the text
that you are asking about; Mike F has done a lot of other work on the
page. Perhaps they can comment.]

On 5 March 2017 at 09:08, Victor Khimenko [off-list ref] wrote:

quoted

syscall(2) example includes the following snippet which explains how to
call readahead on ARM:

       syscall(SYS_readahead, fd, 0,
                   (unsigned int) (offset >> 32),
                   (unsigned int) (offset & 0xFFFFFFFF),
                   count);

But ARM EABI specifies that "A double-word sized type is passed in two
consecutive registers (e.g., r0 and r1, or r2 and r3). The content of
the registers is as if the value had been loaded from memory representation
with a single LDM instruction."

This would imply that arguments are swapped around in the man page, no?

So, I'm taking it that you mean the call should look like this:

       syscall(SYS_readahead, fd, 0,
                   (unsigned int) (offset & 0xFFFFFFFF),
                   (unsigned int) (offset >> 32),
                  count);

Is that what you mean?

quoted

I've tried to experiement and with ftruncate, at least, it works like
this...

Sounds plausible. I'm hoping that Mike or Changhee Han might comment.

it depends on the endianness.  the man page shows BE, and Victor's
suggestion changes it to LE.  we probably need to explain that and
not just swap the args in the example.
-mike

I think that the point is: "invokes the system call whose assembly language interface"

And a lot of new programmes have no experience with assembler these days. So the example
should go into more details an explain how this is mapped into registers.
e.g. ARM/EABI
          syscall(SYS_readahead,                    // r7
                   fd,                              // r0
                    0,                              // r1
                   (unsigned int) (offset >> 32),   // r2
                   (unsigned int) (offset & 0xFFFFFFFF), // r3
                   count);                         //r4

Then the next lines make more sense for the reader:
"       Since  the  offset  argument is 64 bits, and the first argument (fd) is
       passed in r0, the caller must manually split and align the 64-bit value
       so  that it is passed in the r2/r3 register pair.  That means inserting
       a dummy value into r1 (the second argument of 0)."

then adding something like pitfalls:
The programmer needs to be aware of the endianess of is cpu. Big Endian CPU will
need to swap arguments.

@khim-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
what do you think ?

Well, as long as explanation is correct - I'm happy. Would probably
good idea to convert example to Little Endian and mention that "Big
Endian CPU would swap r2 and r3 arguments".

Nowadays most platforms (including most ARM platforms) are Little
Endian thus it looks a bit weird to have Big Endian ARM as canonical
example!

Heck, preadv/pwritev use low/high even on Big Endian platform!

See https://lwn.net/Articles/311630/

That's how I become involved with all that mess: I've tried to
understand the difference between __llseek, pread64 and preadv
syscalls. __llseek uses "hi, lo" arguments order, preadv uses "lo, hi"
and pread64... that's where I've started trying to decypher syscall(2)
man page...

i think your concerns boil down to "the Linux syscall ABI is ugly and
inconsistent".  it is.  some syscalls split 64-bit args naturally, but
some don't.

ARM EABI plumbs the readahead syscall directly to userspace.  that means
the 64-bit value is split according to its low level C ABI.  same for
pread and pread64.  ARM OABI didn't include the padding.

llseek on the other hand takes care of assembling the two 32-bit values
itself in C.

that's why the syscall(2) page contains this caveat:
	However, when using syscall() to make a system call, the caller
	might need to handle architecture-dependent details;
	^^^^^

we can mention the endian issue, but we don't want this page to grow
into details for every syscall.  that's a much larger project that we
discussed at the last LPC.
-mike