Re: AVR32 architecture patch against Linux 2.6.18-rc1 available

[Haavard Skinnemoen <hskinnemoen@atmel.com>]

On Mon, 10 Jul 2006 10:57:33 +0100
David Woodhouse <dwmw2@infradead.org> wrote:

> On Mon, 2006-07-10 at 11:03 +0200, Haavard Skinnemoen wrote:
> +	.global	__sys_pselect6
> +	.type	__sys_pselect6,@function
> +__sys_pselect6:
> +	pushm	lr
> +	st.w	--sp, ARG6
> +	rcall	sys_pselect6
> +	sub	sp, -4
> +	popm	pc
> 
> 
> sys_pselect6() is just a hackish workaround for the fact that most
> architectures don't allow seven-argument syscalls. Having your own
> workaround in assembly, which then calls sys_pselect6(), seems a
> little odd -- why not call sys_pselect7() directly instead from your
> assembly wrapper?

Good point. The reason I did it this way is because I haven't written a
_syscall7() stub for uClibc yet, but I guess I should probably get that
done. I did a quick grep through include/asm-* and didn't find any
other architectures defining __NR_pselect7...

> Stop a moment and work out precisely what the best way to pass the
> arguments _is_ if you have only 5 registers and the stack, perhaps.

The regular AVR32 call convention uses r12-r8 to pass up to 5 arguments
in registers, while any additional arguments are pushed on the stack.

For syscalls, I've modified this to pass the syscall number in r8 and
no arguments on the stack. arg5 is passed in r5 and moved to r8 by the
low-level syscall handler, while arg6 is passed through r3 and pushed
on the stack only if necessary.

So the best way to implement pselect7 is probably to pass the seventh
argument through r2 -- or maybe r4.

> ¹ Note that I'm just _asking_ -- the answer "Uli doesn't want to
> support anything but the basic 6-argument sys_pselect6() in glibc" is
> an acceptable answer on your part.

Well, we haven't actually ported glibc yet. But if 7-argument syscalls
is going to cause problems later, we should probably not do it...

Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/