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 ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
