Date: Tue, 10 Mar 2020 22:18:08 -0400 From: Rich Felker <dalias@...c.org> To: Andreas Dröscher <musl@...free.ch> Cc: musl@...ts.openwall.com Subject: Re: mips32 little endian -ENOSYS is not -(-ENOSYS) On Wed, Mar 11, 2020 at 03:08:22AM +0100, Andreas Dröscher wrote: > >>Sorry for not including that excerpt in the first place: > >> > >>illegal_syscall: > >> li v0, -ENOSYS # error > >> sw v0, PT_R2(sp) > >> li t0, 1 # set error flag > >> sw t0, PT_R7(sp) > >> j o32_syscall_exit > >> END(handle_sys) > >> > >>Source: https://github.com/torvalds/linux/blob/62d0cfcb27cf755cebdc93ca95dabc83608007cd/arch/mips/kernel/scall32-o32.S#L186 > > > >OK, this was fixed by commit bda8229bdd087167f463ad5e74299987924f8137 > >in 2008. But it looks like there's still another path, called > >"einval" from before commit fb498e2570eedc6c9c3d165e370624dfc3aed97b, > >that returns -ENOSYS. All of this is awful, and I think your fix is > >probably the right thing to do. > > Thank you very much for your review. > > Just as a side note. I’ve just figured out that there is a second > issue with old kernels. > > The current implementation of __syscall5, __syscall6 and __syscall7 > (those use caller saved registers) violate the calling conventions > of MIPS32 Linux Kernels prior 2.6.35. Those were assuming that the > instruction immediately preceding the SYSCALL instruction was an > instruction for loading the syscall number. > > I’ll will try to rearrange the stack pushes to accommodate this > requirement and report back if I manage to come up with something > presentable. Uhg, so commit 604f8d3d8b08ee4f548de193050ef93a7753c2e0 was probably wrong and there was a reason for the nonsensical code it removed: making old broken kernels happy. I'm not sure if you can just revert it or need to make new changes. Do you know if this "rule" applies to n32/n64 too or just o32? Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.