* [PATCH] arch: avr32: add dummy syscalls
@ 2013-01-27 12:50 Matthias Brugger
2013-01-27 19:57 ` Hans-Christian Egtvedt
2013-01-28 2:45 ` Håvard Skinnemoen
0 siblings, 2 replies; 17+ messages in thread
From: Matthias Brugger @ 2013-01-27 12:50 UTC (permalink / raw)
To: Haavard Skinnemoen, Hans-Christian Egtvedt, Al Viro,
Andrew Morton, Paul E. McKenney, David Howells, Dave Jones,
Will Deacon, linux-kernel
Cc: 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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
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-28 2:45 ` Håvard Skinnemoen
1 sibling, 1 reply; 17+ messages in thread
From: Hans-Christian Egtvedt @ 2013-01-27 19:57 UTC (permalink / raw)
To: Matthias Brugger
Cc: Haavard Skinnemoen, Al Viro, Andrew Morton, Paul E. McKenney,
David Howells, Dave Jones, Will Deacon, linux-kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-01-27 19:57 ` Hans-Christian Egtvedt
@ 2013-01-27 20:30 ` Al Viro
2013-01-27 20:39 ` Hans-Christian Egtvedt
0 siblings, 1 reply; 17+ messages in thread
From: Al Viro @ 2013-01-27 20:30 UTC (permalink / raw)
To: Hans-Christian Egtvedt
Cc: Matthias Brugger, Haavard Skinnemoen, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
linux-kernel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-01-27 20:30 ` Al Viro
@ 2013-01-27 20:39 ` Hans-Christian Egtvedt
2013-02-04 0:10 ` Al Viro
0 siblings, 1 reply; 17+ messages in thread
From: Hans-Christian Egtvedt @ 2013-01-27 20:39 UTC (permalink / raw)
To: Al Viro
Cc: Matthias Brugger, Haavard Skinnemoen, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
linux-kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-01-27 12:50 [PATCH] arch: avr32: add dummy syscalls Matthias Brugger
2013-01-27 19:57 ` Hans-Christian Egtvedt
@ 2013-01-28 2:45 ` Håvard Skinnemoen
1 sibling, 0 replies; 17+ messages in thread
From: Håvard Skinnemoen @ 2013-01-28 2:45 UTC (permalink / raw)
To: Matthias Brugger
Cc: Hans-Christian Egtvedt, Al Viro, Andrew Morton, Paul E. McKenney,
David Howells, Dave Jones, Will Deacon, Linux Kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-01-27 20:39 ` Hans-Christian Egtvedt
@ 2013-02-04 0:10 ` Al Viro
2013-02-04 0:30 ` Al Viro
0 siblings, 1 reply; 17+ messages in thread
From: Al Viro @ 2013-02-04 0:10 UTC (permalink / raw)
To: Hans-Christian Egtvedt
Cc: Matthias Brugger, Haavard Skinnemoen, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
linux-kernel
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...
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 0:10 ` Al Viro
@ 2013-02-04 0:30 ` Al Viro
2013-02-04 1:31 ` Al Viro
0 siblings, 1 reply; 17+ messages in thread
From: Al Viro @ 2013-02-04 0:30 UTC (permalink / raw)
To: Hans-Christian Egtvedt
Cc: Matthias Brugger, Haavard Skinnemoen, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
linux-kernel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 0:30 ` Al Viro
@ 2013-02-04 1:31 ` Al Viro
2013-02-04 3:02 ` Al Viro
2013-02-04 3:21 ` H. Peter Anvin
0 siblings, 2 replies; 17+ messages in thread
From: Al Viro @ 2013-02-04 1:31 UTC (permalink / raw)
To: Hans-Christian Egtvedt
Cc: Matthias Brugger, Haavard Skinnemoen, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
linux-kernel
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 ;-/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
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 3:21 ` H. Peter Anvin
1 sibling, 1 reply; 17+ messages in thread
From: Al Viro @ 2013-02-04 3:02 UTC (permalink / raw)
To: Hans-Christian Egtvedt
Cc: Matthias Brugger, Haavard Skinnemoen, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
linux-kernel
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 ;-/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 1:31 ` Al Viro
2013-02-04 3:02 ` Al Viro
@ 2013-02-04 3:21 ` H. Peter Anvin
1 sibling, 0 replies; 17+ messages in thread
From: H. Peter Anvin @ 2013-02-04 3:21 UTC (permalink / raw)
To: Al Viro
Cc: Hans-Christian Egtvedt, Matthias Brugger, Haavard Skinnemoen,
Andrew Morton, Paul E. McKenney, David Howells, Dave Jones,
Will Deacon, linux-kernel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 3:02 ` Al Viro
@ 2013-02-04 4:52 ` Håvard Skinnemoen
2013-02-04 5:05 ` Al Viro
0 siblings, 1 reply; 17+ messages in thread
From: Håvard Skinnemoen @ 2013-02-04 4:52 UTC (permalink / raw)
To: Al Viro
Cc: Hans-Christian Egtvedt, Matthias Brugger, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
Linux Kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 4:52 ` Håvard Skinnemoen
@ 2013-02-04 5:05 ` Al Viro
2013-02-04 5:35 ` Håvard Skinnemoen
0 siblings, 1 reply; 17+ messages in thread
From: Al Viro @ 2013-02-04 5:05 UTC (permalink / raw)
To: H?vard Skinnemoen
Cc: Hans-Christian Egtvedt, Matthias Brugger, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
Linux Kernel
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...
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 5:05 ` Al Viro
@ 2013-02-04 5:35 ` Håvard Skinnemoen
2013-02-04 15:39 ` Al Viro
0 siblings, 1 reply; 17+ messages in thread
From: Håvard Skinnemoen @ 2013-02-04 5:35 UTC (permalink / raw)
To: Al Viro
Cc: Hans-Christian Egtvedt, Matthias Brugger, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
Linux Kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 5:35 ` Håvard Skinnemoen
@ 2013-02-04 15:39 ` Al Viro
2013-02-04 16:34 ` Håvard Skinnemoen
0 siblings, 1 reply; 17+ messages in thread
From: Al Viro @ 2013-02-04 15:39 UTC (permalink / raw)
To: H?vard Skinnemoen
Cc: Hans-Christian Egtvedt, Matthias Brugger, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
Linux Kernel
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...
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 15:39 ` Al Viro
@ 2013-02-04 16:34 ` Håvard Skinnemoen
2013-02-04 22:53 ` Al Viro
2013-02-05 8:06 ` Hans-Christian Egtvedt
0 siblings, 2 replies; 17+ messages in thread
From: Håvard Skinnemoen @ 2013-02-04 16:34 UTC (permalink / raw)
To: Al Viro
Cc: Hans-Christian Egtvedt, Matthias Brugger, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
Linux Kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 16:34 ` Håvard Skinnemoen
@ 2013-02-04 22:53 ` Al Viro
2013-02-05 8:06 ` Hans-Christian Egtvedt
1 sibling, 0 replies; 17+ messages in thread
From: Al Viro @ 2013-02-04 22:53 UTC (permalink / raw)
To: H?vard Skinnemoen
Cc: Hans-Christian Egtvedt, Matthias Brugger, Andrew Morton,
Paul E. McKenney, David Howells, Dave Jones, Will Deacon,
Linux Kernel
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arch: avr32: add dummy syscalls
2013-02-04 16:34 ` Håvard Skinnemoen
2013-02-04 22:53 ` Al Viro
@ 2013-02-05 8:06 ` Hans-Christian Egtvedt
1 sibling, 0 replies; 17+ messages in thread
From: Hans-Christian Egtvedt @ 2013-02-05 8:06 UTC (permalink / raw)
To: Håvard Skinnemoen
Cc: Al Viro, Matthias Brugger, Andrew Morton, Paul E. McKenney,
David Howells, Dave Jones, Will Deacon, Linux Kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-02-05 8:06 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2013-02-05 8:06 ` Hans-Christian Egtvedt
2013-02-04 3:21 ` H. Peter Anvin
2013-01-28 2:45 ` Håvard Skinnemoen
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).