[PATCH] arch: avr32: add dummy syscalls

[PATCH] arch: avr32: add dummy syscalls

[Matthias Brugger]

This patch adds dummy syscalls so that compiling
for this architecture does not provoke warnings when
checksyscalls.sh is called.

Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
 arch/avr32/include/asm/unistd.h      |  2 +-
 arch/avr32/include/uapi/asm/unistd.h | 29 +++++++++++++++++++++++++++++
 arch/avr32/kernel/syscall_table.S    | 29 +++++++++++++++++++++++++++++
 3 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/arch/avr32/include/asm/unistd.h b/arch/avr32/include/asm/unistd.h
index 0bdf637..570c100 100644
--- a/arch/avr32/include/asm/unistd.h
+++ b/arch/avr32/include/asm/unistd.h
@@ -10,7 +10,7 @@
 
 #include <uapi/asm/unistd.h>
 
-#define NR_syscalls		284
+#define NR_syscalls		312
 
 /* Old stuff */
 #define __IGNORE_uselib
diff --git a/arch/avr32/include/uapi/asm/unistd.h b/arch/avr32/include/uapi/asm/unistd.h
index 3eaa687..51c0e76 100644
--- a/arch/avr32/include/uapi/asm/unistd.h
+++ b/arch/avr32/include/uapi/asm/unistd.h
@@ -301,5 +301,34 @@
 #define __NR_eventfd		281
 #define __NR_setns		283
 
+#define __NR_epoll_create1	285
+#define __NR_pread64		286
+#define __NR_pwrite64		286
+#define __NR_timerfd_create	287
+#define __NR_fallocate		288
+#define __NR_timerfd_settime	289
+#define __NR_timerfd_gettime	290
+#define __NR_signalfd4		291
+#define __NR_eventfd2		292
+#define __NR_dup3		293
+#define __NR_pipe2		294
+#define __NR_inotify_init1	295
+#define __NR_preadv		296
+#define __NR_pwritev		297
+#define __NR_rt_tgsigqueueinfo	298
+#define __NR_perf_event_open	299
+#define __NR_recvmmsg		300
+#define __NR_fanotify_init	301
+#define __NR_fanotify_mark	302
+#define __NR_prlimit64		303
+#define __NR_name_to_handle_at	304
+#define __NR_open_by_handle_at	305
+#define __NR_clock_adjtime	306
+#define __NR_syncfs		307
+#define __NR_sendmmsg		308
+#define __NR_process_vm_readv	309
+#define __NR_process_vm_writev	310
+#define __NR_kcmp		311
+#define __NR_finit_module	312
 
 #endif /* _UAPI__ASM_AVR32_UNISTD_H */
diff --git a/arch/avr32/kernel/syscall_table.S b/arch/avr32/kernel/syscall_table.S
index f27bb87..6ad2330 100644
--- a/arch/avr32/kernel/syscall_table.S
+++ b/arch/avr32/kernel/syscall_table.S
@@ -298,3 +298,32 @@ sys_call_table:
 	.long	sys_recvmmsg
 	.long	sys_setns
 	.long	sys_ni_syscall		/* r8 is saturated at nr_syscalls */
+	.long	sys_epoll_create1	/* 285 */
+	.long	sys_pread64
+	.long	sys_pwrite64
+	.long	sys_timerfd_create
+	.long	sys_fallocate
+	.long	sys_timerfd_settime
+	.long	sys_timerfd_gettime /* 290 */
+	.long	sys_signalfd4
+	.long	sys_eventfd2
+	.long	sys_dup3
+	.long	sys_pipe2
+	.long	sys_inotify_init1 /* 295 */
+	.long	sys_preadv
+	.long	sys_pwritev
+	.long	sys_rt_tgsigqueueinfo
+	.long	sys_perf_event_open
+	.long	sys_recvmmsg /* 300 */
+	.long	sys_fanotify_init
+	.long	sys_fanotify_mark
+	.long	sys_prlimit64
+	.long	sys_name_to_handle_at
+	.long	sys_open_by_handle_at /* 305 */
+	.long	sys_clock_adjtime
+	.long	sys_syncfs
+	.long	sys_sendmmsg
+	.long	sys_process_vm_readv
+	.long	sys_process_vm_writev /* 310 */
+	.long	sys_kcmp
+	.long	sys_finit_module
-- 
1.7.11.7

Re: [PATCH] arch: avr32: add dummy syscalls

[Hans-Christian Egtvedt]

Around Sun 27 Jan 2013 13:50:15 +0100 or thereabout, Matthias Brugger wrote:
> This patch adds dummy syscalls so that compiling
> for this architecture does not provoke warnings when
> checksyscalls.sh is called.

Does any of these syscalls take more than 5 arguments? If so, it is also
needed to do some stack handling. I would rather not add syscalls that cause
the kernel to misbehave.

> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
>  arch/avr32/include/asm/unistd.h      |  2 +-
>  arch/avr32/include/uapi/asm/unistd.h | 29 +++++++++++++++++++++++++++++
>  arch/avr32/kernel/syscall_table.S    | 29 +++++++++++++++++++++++++++++
>  3 files changed, 59 insertions(+), 1 deletion(-)

<snipp diff>

-- 
mvh
Hans-Christian Egtvedt

Re: [PATCH] arch: avr32: add dummy syscalls

[Al Viro]

On Sun, Jan 27, 2013 at 08:57:14PM +0100, Hans-Christian Egtvedt wrote:
> Around Sun 27 Jan 2013 13:50:15 +0100 or thereabout, Matthias Brugger wrote:
> > This patch adds dummy syscalls so that compiling
> > for this architecture does not provoke warnings when
> > checksyscalls.sh is called.
> 
> Does any of these syscalls take more than 5 arguments? If so, it is also
> needed to do some stack handling. I would rather not add syscalls that cause
> the kernel to misbehave.

BTW, it might make sense to teach SYSCALL_DEFINE6 to generate such a wrapper
on avr32.  How about something along the lines of
* SYSCALL_DEFINE6(foo, ...) generating (via asm volatile, right next to
sys_foo())
__sys_##foo:
        pushm   lr
        st.w    --sp, r3
	call	sys_##foo
        sub     sp, -4
        popm    pc
* SYSCALL_DEFINE[0..5](foo, ...) generating
	SYSCALL_ALIAS(__sys_foo, sys_foo)
* syscall_table.S beginning with
        .section .rodata,"a",@progbits
        .type   sys_call_table,@object
        .global sys_call_table
        .align  2
#define SYS(name) __sys_##name
sys_call_table:
        SYS(restart_syscall)
	SYS(exit)
	SYS(fork)
	...

If you are OK with going that way, I could probably put together patches doing
just that.  Note that for rt_sigsuspend/rt_sigreturn/sigaltstack the wrappers
are not needed at all - they can just use current_pt_regs() in syscall body.
IOW, all of syscall-stubs.S could be killed.

Re: [PATCH] arch: avr32: add dummy syscalls

[Hans-Christian Egtvedt]

Around Sun 27 Jan 2013 20:30:09 +0000 or thereabout, Al Viro wrote:
> On Sun, Jan 27, 2013 at 08:57:14PM +0100, Hans-Christian Egtvedt wrote:
>> Around Sun 27 Jan 2013 13:50:15 +0100 or thereabout, Matthias Brugger wrote:
>> > This patch adds dummy syscalls so that compiling
>> > for this architecture does not provoke warnings when
>> > checksyscalls.sh is called.
>> 
>> Does any of these syscalls take more than 5 arguments? If so, it is also
>> needed to do some stack handling. I would rather not add syscalls that cause
>> the kernel to misbehave.
> 
> BTW, it might make sense to teach SYSCALL_DEFINE6 to generate such a wrapper
> on avr32.  How about something along the lines of
> * SYSCALL_DEFINE6(foo, ...) generating (via asm volatile, right next to
> sys_foo())
> __sys_##foo:
>         pushm   lr
>         st.w    --sp, r3
> 	call	sys_##foo
>         sub     sp, -4
>         popm    pc
> * SYSCALL_DEFINE[0..5](foo, ...) generating
> 	SYSCALL_ALIAS(__sys_foo, sys_foo)
> * syscall_table.S beginning with
>         .section .rodata,"a",@progbits
>         .type   sys_call_table,@object
>         .global sys_call_table
>         .align  2
> #define SYS(name) __sys_##name
> sys_call_table:
>         SYS(restart_syscall)
> 	SYS(exit)
> 	SYS(fork)
> 	...
> 
> If you are OK with going that way, I could probably put together patches doing
> just that.  Note that for rt_sigsuspend/rt_sigreturn/sigaltstack the wrappers
> are not needed at all - they can just use current_pt_regs() in syscall body.
> IOW, all of syscall-stubs.S could be killed.

Nice, could you put together the preprocessor stuff in a patch? It would be
great to not having to write a re-occuring stub for each syscall that has 6+
arguments.

Thanks for looking at this.

-- 
mvh
Hans-Christian Egtvedt

Re: [PATCH] arch: avr32: add dummy syscalls

[Håvard Skinnemoen]

On Sun, Jan 27, 2013 at 7:50 PM, Matthias Brugger
<matthias.bgg@gmail.com> wrote:
> This patch adds dummy syscalls so that compiling
> for this architecture does not provoke warnings when
> checksyscalls.sh is called.

Nice, but...

> --- a/arch/avr32/kernel/syscall_table.S
> +++ b/arch/avr32/kernel/syscall_table.S
> @@ -298,3 +298,32 @@ sys_call_table:
>         .long   sys_recvmmsg
>         .long   sys_setns
>         .long   sys_ni_syscall          /* r8 is saturated at nr_syscalls */

This terminator needs to stay at the end. Its only purpose is to allow
us to save a cycle or two when saturating the system call number.

Also, Al's suggestion sounds good to me.

Havard

Re: [PATCH] arch: avr32: add dummy syscalls

[Al Viro]

On Sun, Jan 27, 2013 at 09:39:54PM +0100, Hans-Christian Egtvedt wrote:
> > If you are OK with going that way, I could probably put together patches doing
> > just that.  Note that for rt_sigsuspend/rt_sigreturn/sigaltstack the wrappers
> > are not needed at all - they can just use current_pt_regs() in syscall body.
> > IOW, all of syscall-stubs.S could be killed.
> 
> Nice, could you put together the preprocessor stuff in a patch? It would be
> great to not having to write a re-occuring stub for each syscall that has 6+
> arguments.
> 
> Thanks for looking at this.

Apologies about the delay...  One question: what's the AVR32 C ABI for
passing 64bit arguments?  The tricky bugger is sys_sync_file_range();
it takes (s32, s64, s64, u32) as arguments and if not any pair of
registers can be used to pass 64bit value, we have more serious trouble
there...

Re: [PATCH] arch: avr32: add dummy syscalls

[Al Viro]

On Mon, Feb 04, 2013 at 12:10:55AM +0000, Al Viro wrote:
> On Sun, Jan 27, 2013 at 09:39:54PM +0100, Hans-Christian Egtvedt wrote:
> > > If you are OK with going that way, I could probably put together patches doing
> > > just that.  Note that for rt_sigsuspend/rt_sigreturn/sigaltstack the wrappers
> > > are not needed at all - they can just use current_pt_regs() in syscall body.
> > > IOW, all of syscall-stubs.S could be killed.
> > 
> > Nice, could you put together the preprocessor stuff in a patch? It would be
> > great to not having to write a re-occuring stub for each syscall that has 6+
> > arguments.
> > 
> > Thanks for looking at this.
> 
> Apologies about the delay...  One question: what's the AVR32 C ABI for
> passing 64bit arguments?  The tricky bugger is sys_sync_file_range();
> it takes (s32, s64, s64, u32) as arguments and if not any pair of
> registers can be used to pass 64bit value, we have more serious trouble
> there...

BTW, it's worse: both fadivse64 and fadvise64_64 are wired, neither of them
has a wrapper and arguments are (s32, s64, u32, s32) and (s32, s64, s64, s32)
resp.  The former is OK unless you have restrictions on register pairs that
can be used for 64bit; the latter is past the 5-register limit no matter what,
so the wrapper is really needed.

Re: [PATCH] arch: avr32: add dummy syscalls

[Al Viro]

On Mon, Feb 04, 2013 at 12:30:47AM +0000, Al Viro wrote:
> On Mon, Feb 04, 2013 at 12:10:55AM +0000, Al Viro wrote:
> > On Sun, Jan 27, 2013 at 09:39:54PM +0100, Hans-Christian Egtvedt wrote:
> > > > If you are OK with going that way, I could probably put together patches doing
> > > > just that.  Note that for rt_sigsuspend/rt_sigreturn/sigaltstack the wrappers
> > > > are not needed at all - they can just use current_pt_regs() in syscall body.
> > > > IOW, all of syscall-stubs.S could be killed.
> > > 
> > > Nice, could you put together the preprocessor stuff in a patch? It would be
> > > great to not having to write a re-occuring stub for each syscall that has 6+
> > > arguments.
> > > 
> > > Thanks for looking at this.
> > 
> > Apologies about the delay...  One question: what's the AVR32 C ABI for
> > passing 64bit arguments?  The tricky bugger is sys_sync_file_range();
> > it takes (s32, s64, s64, u32) as arguments and if not any pair of
> > registers can be used to pass 64bit value, we have more serious trouble
> > there...
> 
> BTW, it's worse: both fadivse64 and fadvise64_64 are wired, neither of them
> has a wrapper and arguments are (s32, s64, u32, s32) and (s32, s64, s64, s32)
> resp.  The former is OK unless you have restrictions on register pairs that
> can be used for 64bit; the latter is past the 5-register limit no matter what,
> so the wrapper is really needed.

Unless I'm misreading ocavr32.pdf, that should be (R12, R10:R11, R9, R8) and
(R12, R10:R11, R9:R8, stack) resp., so fadvise64 doesn't need a wrapper, but
fadvise64_64 does.  And something like (s32, s32, s64, s64) would turn into
(R12, R11, R9:R8, stack, stack); AFAICS, we don't have anything that ugly...

Automating *that* is going to be interesting...  I've not given up, but it's
not going to be fun ;-/

Re: [PATCH] arch: avr32: add dummy syscalls

[Al Viro]

On Mon, Feb 04, 2013 at 01:31:11AM +0000, Al Viro wrote:

> Unless I'm misreading ocavr32.pdf, that should be (R12, R10:R11, R9, R8) and
> (R12, R10:R11, R9:R8, stack) resp., so fadvise64 doesn't need a wrapper, but
> fadvise64_64 does.  And something like (s32, s32, s64, s64) would turn into
> (R12, R11, R9:R8, stack, stack); AFAICS, we don't have anything that ugly...

Oh, yes, we do - fallocate(2).  int fd, int mode, loff_t offset, loff_t len.
On something like mips or sparc32 it packs nicely; on avr32 it doesn't.
Could you confirm that I haven't misparsed the ABI?

> Automating *that* is going to be interesting...  I've not given up, but it's
> not going to be fun ;-/

Re: [PATCH] arch: avr32: add dummy syscalls

[H. Peter Anvin]

On 02/03/2013 05:31 PM, Al Viro wrote:
>
> Unless I'm misreading ocavr32.pdf, that should be (R12, R10:R11, R9, R8) and
> (R12, R10:R11, R9:R8, stack) resp., so fadvise64 doesn't need a wrapper, but
> fadvise64_64 does.  And something like (s32, s32, s64, s64) would turn into
> (R12, R11, R9:R8, stack, stack); AFAICS, we don't have anything that ugly...
>
> Automating *that* is going to be interesting...  I've not given up, but it's
> not going to be fun ;-/
>

Feel free to steal machinery from klibc... it has scripts to 
autogenerate stubs for arbitrary ABIs.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH] arch: avr32: add dummy syscalls

[Håvard Skinnemoen]

On Sun, Feb 3, 2013 at 7:02 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Mon, Feb 04, 2013 at 01:31:11AM +0000, Al Viro wrote:
>
>> Unless I'm misreading ocavr32.pdf, that should be (R12, R10:R11, R9, R8) and
>> (R12, R10:R11, R9:R8, stack) resp., so fadvise64 doesn't need a wrapper, but
>> fadvise64_64 does.  And something like (s32, s32, s64, s64) would turn into
>> (R12, R11, R9:R8, stack, stack); AFAICS, we don't have anything that ugly...
>
> Oh, yes, we do - fallocate(2).  int fd, int mode, loff_t offset, loff_t len.
> On something like mips or sparc32 it packs nicely; on avr32 it doesn't.
> Could you confirm that I haven't misparsed the ABI?

You're right on -- in this case, the compiler will skip r10, and do
(r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
also unconditionally move r7 to r8 in the syscall path, so it
shouldn't matter (libc does the opposite when necessary).

I remember some talk about having the compiler reuse r10 for the next
32-bit argument in cases like this, but I don't think it ever
happened.

Havard

Re: [PATCH] arch: avr32: add dummy syscalls

[Al Viro]

On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote:

> You're right on -- in this case, the compiler will skip r10, and do
> (r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
> also unconditionally move r7 to r8 in the syscall path, so it
> shouldn't matter (libc does the opposite when necessary).
> 
> I remember some talk about having the compiler reuse r10 for the next
> 32-bit argument in cases like this, but I don't think it ever
> happened.

Umm...  In case of fallocate() the next argument is 64bit one, though;
sys_fallocate() will be looking for two 32bit words on stack, so no
matter how do we pass them to syscall, we'd better push two words in
the wrapper.

But yes, 32bit/32bit/64bit/32bit is another interesting case -
fanotify_mark is 32/32/64/32/32.  From what ABI says it would seem to
be r12/r11/r8:r9/r10/stack, but if I understand you correctly, we'll
end up wanting *two* arguments on stack...

Re: [PATCH] arch: avr32: add dummy syscalls

[Håvard Skinnemoen]

On Sun, Feb 3, 2013 at 9:05 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Feb 03, 2013 at 08:52:18PM -0800, H?vard Skinnemoen wrote:
>
>> You're right on -- in this case, the compiler will skip r10, and do
>> (r12, r11, r8:r9, stack). We pass the syscall number in r8, but we
>> also unconditionally move r7 to r8 in the syscall path, so it
>> shouldn't matter (libc does the opposite when necessary).
>>
>> I remember some talk about having the compiler reuse r10 for the next
>> 32-bit argument in cases like this, but I don't think it ever
>> happened.
>
> Umm...  In case of fallocate() the next argument is 64bit one, though;
> sys_fallocate() will be looking for two 32bit words on stack, so no
> matter how do we pass them to syscall, we'd better push two words in
> the wrapper.

Right.

> But yes, 32bit/32bit/64bit/32bit is another interesting case -
> fanotify_mark is 32/32/64/32/32.  From what ABI says it would seem to
> be r12/r11/r8:r9/r10/stack, but if I understand you correctly, we'll
> end up wanting *two* arguments on stack...

Yes, I think there may be a difference between the IAR and gcc ABI
here. But I could be wrong.

Havard

Re: [PATCH] arch: avr32: add dummy syscalls

[Al Viro]

On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote:

> Right.
> 
> > But yes, 32bit/32bit/64bit/32bit is another interesting case -
> > fanotify_mark is 32/32/64/32/32.  From what ABI says it would seem to
> > be r12/r11/r8:r9/r10/stack, but if I understand you correctly, we'll
> > end up wanting *two* arguments on stack...
> 
> Yes, I think there may be a difference between the IAR and gcc ABI
> here. But I could be wrong.

Umm...  avr32_function_arg() in atmel 4.4.3 patch:
  if (arg_rsize == 8)
    {
      /* use r11:r10 or r9:r8. */
      if (!(GET_USED_INDEX (cum, 1) || GET_USED_INDEX (cum, 2)))
       index = 1;
      else if ((last_reg_index == 4) &&
               !(GET_USED_INDEX (cum, 3) || GET_USED_INDEX (cum, 4)))
       index = 3;
      else
       index = -1;
    }
  else if (arg_rsize == 4)
    {                          /* Use first available register */
      index = 0;
      while (index <= last_reg_index && GET_USED_INDEX (cum, index))
       index++;
      if (index > last_reg_index)
       index = -1;
    }

So it will use the gap in case of 32/32/64/32; the first two calls will
take index 0 and 1 (r12 and r11 resp.), the third will take 3 and 4
(r9:r8) and the fourth will take 2 (r10).  Relevant part of
avr32_function_arg_advance():
  /* Mark the used registers as "used". */
  if (GET_REG_INDEX (cum) >= 0)
    {
      SET_USED_INDEX (cum, GET_REG_INDEX (cum));
      if (arg_rsize == 8)
       {
         SET_USED_INDEX (cum, (GET_REG_INDEX (cum) + 1));
       }
    }
i.e. the third argument will only stomp on 3 and 4, leaving 2 unused.

And as far as I can see, their 4.3.3 patch does the same thing...

Re: [PATCH] arch: avr32: add dummy syscalls

[Håvard Skinnemoen]

On Mon, Feb 4, 2013 at 7:39 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote:
>>
>> > But yes, 32bit/32bit/64bit/32bit is another interesting case -
>> > fanotify_mark is 32/32/64/32/32.  From what ABI says it would seem to
>> > be r12/r11/r8:r9/r10/stack, but if I understand you correctly, we'll
>> > end up wanting *two* arguments on stack...
>>
>> Yes, I think there may be a difference between the IAR and gcc ABI
>> here. But I could be wrong.
>
> So it will use the gap in case of 32/32/64/32; the first two calls will
> take index 0 and 1 (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.

Havard

Re: [PATCH] arch: avr32: add dummy syscalls

[Al Viro]

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?

Re: [PATCH] arch: avr32: add dummy syscalls

[Hans-Christian Egtvedt]

Around Mon 04 Feb 2013 08:34:47 -0800 or thereabout, Håvard Skinnemoen wrote:
> On Mon, Feb 4, 2013 at 7:39 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> On Sun, Feb 03, 2013 at 09:35:39PM -0800, H?vard Skinnemoen wrote:
>>>
>>> > But yes, 32bit/32bit/64bit/32bit is another interesting case -
>>> > fanotify_mark is 32/32/64/32/32.  From what ABI says it would seem to
>>> > be r12/r11/r8:r9/r10/stack, but if I understand you correctly, we'll
>>> > end up wanting *two* arguments on stack...
>>>
>>> Yes, I think there may be a difference between the IAR and gcc ABI
>>> here. But I could be wrong.
>>
>> So it will use the gap in case of 32/32/64/32; the first two calls will
>> take index 0 and 1 (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.

The last avr32-linux toolchain I was able to build was 4.2.x, the openwrt
people got 4.3.x to build and produce a bootable system.

I have not tested the 4.4.x GCC port from Atmel.

-- 
mvh
Hans-Christian Egtvedt