linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: H?vard Skinnemoen <hskinnemoen@gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	David Howells <dhowells@redhat.com>,
	Dave Jones <davej@redhat.com>, Will Deacon <will.deacon@arm.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arch: avr32: add dummy syscalls
Date: Mon, 4 Feb 2013 22:53:44 +0000	[thread overview]
Message-ID: <20130204225343.GD4503@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CACiLriQeYGGj5WZrf8H8z5N-AG1z_tDH7cXsd1J7ptpqYenPpw@mail.gmail.com>

On Mon, Feb 04, 2013 at 08:34:47AM -0800, H?vard Skinnemoen wrote:

> > So it will use the gap in case of 32/32/64/32; the first two calls will
> > take index 0 and 64bit (r12 and r11 resp.), the third will take 3 and 4
> > (r9:r8) and the fourth will take 2 (r10).
> 
> Oh, cool. I guess I am wrong then. Thanks a lot for taking the time to
> figure this out, and sorry I misled you.
> 
> If someone's got the toolchain installed (which I don't, sorry), it
> should be relatively straightforward to verify this by looking at the
> disassembly of a call to a function with a similar prototype.

Ho-hum...
	* no regular syscalls for 32bit host have more than 192 (6*32) bits
worth of arguments (sys_syscall() takes up to 7*32, but that weirdness is
neither common nor desirable - it's compatibility-only stuff).
	* for C ABI on avr32 we have the following (sorted by the total size)
32bit  -> r12
32bit 32bit  -> r12 r11
64bit  -> r10:r11
32bit 32bit 32bit  -> r12 r11 r10
32bit 64bit  -> r12 r10:r11
64bit 32bit  -> r10:r11 r12  
32bit 32bit 32bit 32bit  -> r12 r11 r10 r9
32bit 32bit 64bit  -> r12 r11 r9:r8
32bit 64bit 32bit  -> r12 r10:r11 r9
64bit 32bit 32bit  -> r10:r11 r12 r9   
64bit 64bit  -> r10:r11 r9:r8   
32bit 32bit 32bit 32bit 32bit  -> r12 r11 r10 r9 r8
32bit 32bit 32bit 64bit  -> r12 r11 r10 r9:r8
32bit 32bit 64bit 32bit  -> r12 r11 r9:r8 r10
32bit 64bit 32bit 32bit  -> r12 r10:r11 r9 r8
32bit 64bit 64bit  -> r12 r10:r11 r9:r8
64bit 32bit 32bit 32bit  -> r10:r11 r12 r9 r8
64bit 32bit 64bit  -> r10:r11 r12 r9:r8  
64bit 64bit 32bit  -> r10:r11 r9:r8 r12  
32bit 32bit 32bit 32bit 32bit 32bit  -> r12 r11 r10 r9 r8 s
32bit 32bit 32bit 32bit 64bit  -> r12 r11 r10 r9 s:s
32bit 32bit 32bit 64bit 32bit  -> r12 r11 r10 r9:r8 s
32bit 32bit 64bit 32bit 32bit  -> r12 r11 r9:r8 r10 s
32bit 32bit 64bit 64bit  -> r12 r11 r9:r8 s:s
32bit 64bit 32bit 32bit 32bit  -> r12 r10:r11 r9 r8 s
32bit 64bit 32bit 64bit  -> r12 r10:r11 r9 s:s 
32bit 64bit 64bit 32bit  -> r12 r10:r11 r9:r8 s
64bit 32bit 32bit 32bit 32bit  -> r10:r11 r12 r9 r8 s
64bit 32bit 32bit 64bit  -> r10:r11 r12 r9 s:s
64bit 32bit 64bit 32bit  -> r10:r11 r12 r9:r8 s
64bit 64bit 32bit 32bit  -> r10:r11 r9:r8 r12 s
64bit 64bit 64bit  -> r10:r11 r9:r8 s:s
	* syscall ABI coincides with C one if neither r8 nor stack is used.
	* if C ABI would use r8 but not stack, syscall one uses r5 instead
of r8.
	* plain SYSCALL_DEFINE6 syscalls have
32bit 32bit 32bit 32bit 32bit 32bit  -> r12 r11 r10 r9 r5 r3
At least in one case the wrapper is missing for a wired syscall - sys_futex
is used as-is.
	* sync_file_range(2) is wired as
32bit 64bit 64bit 32bit  -> r12 r10:r11 r9:r5 r3
	* fadvise64_64(2) is missing a wrapper; same arguments as for
sync_file_range(), presumably with the same calling conventions
	* fanotify_mark(2) is not wired; presumably should be
32bit 32bit 64bit 32bit 32bit  -> r12 r11 r9:r5 r10 r3
	* sync_file_range2(2) (which is not going to be wired) and fallocate(2)
(which probably will) have the same argument types; calling conventions should
probably be something like
32bit 32bit 64bit 64bit  -> r12 r11 r9:r5 ?:?
libc function is going to have arguments in r12, r11, r9:r8 and in two
32bit words on stack, so libc-side glue should be
	r5 = r8
	r8 = __NR_fallocate
	r<something> = lower 32 bits of 'len' (sits on stack)
	r<something else> = upper 32 bits of 'len' (sits on stack)
Looks like it ought to be r10 and r3, if we want to keep the same set
of registers?

There are several argument type combinations that are not used at the moment,
but migth appear in the future; ones that have only one word passed on stack
should probably go the same way we deal with the SYSCALL_DEFINE6 ones, but
ones that spill *two* words on stack are really interesting.  In addition to
fallocate(2) [gap in r10, two words on stack], we have
32bit 32bit 32bit 32bit 64bit
32bit 64bit 32bit 64bit
64bit 32bit 32bit 64bit [gap in r8, two words on stack] and
64bit 64bit 64bit [gap in r12, two words on stack]

What calling conventions would we want for those?

  reply	other threads:[~2013-02-04 22:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-27 12:50 [PATCH] arch: avr32: add dummy syscalls Matthias Brugger
2013-01-27 19:57 ` Hans-Christian Egtvedt
2013-01-27 20:30   ` Al Viro
2013-01-27 20:39     ` Hans-Christian Egtvedt
2013-02-04  0:10       ` Al Viro
2013-02-04  0:30         ` Al Viro
2013-02-04  1:31           ` Al Viro
2013-02-04  3:02             ` Al Viro
2013-02-04  4:52               ` Håvard Skinnemoen
2013-02-04  5:05                 ` Al Viro
2013-02-04  5:35                   ` Håvard Skinnemoen
2013-02-04 15:39                     ` Al Viro
2013-02-04 16:34                       ` Håvard Skinnemoen
2013-02-04 22:53                         ` Al Viro [this message]
2013-02-05  8:06                         ` Hans-Christian Egtvedt
2013-02-04  3:21             ` H. Peter Anvin
2013-01-28  2:45 ` Håvard Skinnemoen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130204225343.GD4503@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=egtvedt@samfundet.no \
    --cc=hskinnemoen@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).