Re: [PATCH] arch: avr32: add dummy syscalls
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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 v...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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 = lower 32 bits of 'len' (sits on stack) r = 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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Mon, Feb 4, 2013 at 7:39 AM, Al Viro 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Mon, Feb 4, 2013 at 7:39 AM, Al Viro v...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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 rsomething = lower 32 bits of 'len' (sits on stack) rsomething 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? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Sun, Feb 3, 2013 at 9:05 PM, Al Viro 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Sun, Feb 3, 2013 at 7:02 PM, Al Viro wrote: > On Mon, Feb 04, 2013 at 01:31:11AM +, 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Mon, Feb 04, 2013 at 01:31:11AM +, 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 ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Mon, Feb 04, 2013 at 12:30:47AM +, Al Viro wrote: > On Mon, Feb 04, 2013 at 12:10:55AM +, 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 ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Mon, Feb 04, 2013 at 12:10:55AM +, 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Mon, Feb 04, 2013 at 12:10:55AM +, 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Mon, Feb 04, 2013 at 12:30:47AM +, Al Viro wrote: On Mon, Feb 04, 2013 at 12:10:55AM +, 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 ;-/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Mon, Feb 04, 2013 at 01:31:11AM +, 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 ;-/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Sun, Feb 3, 2013 at 7:02 PM, Al Viro v...@zeniv.linux.org.uk wrote: On Mon, Feb 04, 2013 at 01:31:11AM +, 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Sun, Feb 3, 2013 at 9:05 PM, Al Viro v...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Sun, Jan 27, 2013 at 7:50 PM, Matthias Brugger 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
Around Sun 27 Jan 2013 20:30:09 + 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 > callsys_##foo > sub sp, -4 > popmpc > * 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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 callsys_##foo sub sp, -4 popmpc * 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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 > --- > 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(-) -- mvh Hans-Christian Egtvedt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch: avr32: add dummy syscalls
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 --- 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 -#define NR_syscalls284 +#define NR_syscalls312 /* 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_create287 +#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_preadv296 +#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_syncfs307 +#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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch: avr32: add dummy syscalls
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@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_syscalls284 +#define NR_syscalls312 /* 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_create287 +#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_preadv296 +#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_syncfs307 +#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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
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 callsys_##foo sub sp, -4 popmpc * 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
Around Sun 27 Jan 2013 20:30:09 + 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 callsys_##foo sub sp, -4 popmpc * 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: avr32: add dummy syscalls
On Sun, Jan 27, 2013 at 7:50 PM, Matthias Brugger matthias@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
