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 _______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
