On Thu, Sep 25, 2008 at 05:01:36PM +1000, Benjamin Herrenschmidt wrote:

I noticed that our ABI says callers are responsible for sign extending.
That means that all int, long or similarly signed arguments to syscalls
must be explicitly sign-extended.

We already have wrappers to do that for -some- syscalls in arch code.
Those are in C and pretty ugly, copy/pasting a bunch of identically
useless comments all over, and are missing a lot of potential
candidates.

sparc64 uses a nicer macro system to generate trampolines in asm. It
also has a more complete list. But it's also missing some :-)

Now, there is a good point to be made that we don't absolutely need to
always sign extend. In many cases, the called function will just do a
cmplw for example, or an and to test bits in flags, and so it looks like
sign extension is not necessary. One could say that sign extending file
descriptors for example isn't terribly useful

But that sounds like a fragile approach to me. We don't know for sure
what new tricks the compiler will learn for example. In fact, when
taking the sparc64 list, I noticed that in some cases it -did- already
sign extend file descriptors and flags .. and in some cases not.

So I've spent a few hours combing through all of syscalls.h (and one
more that seems to be missing from this file, ie, pipe2, there may be
others) for anything using int, long or pid_t (which is signed, at least
on our 32-bit platforms).

You might want to look at functions that take clockid_t as well.  It's also
a signed int.  We recently ran into a case of this for clock_getres on ppc64
using a 32-bit glibc.  Albiet, on a quite old kernel but looking at it briefly
it seems to still be an issue, so probably worth fixing.

josh