Re: [musl] mips32 little endian -ENOSYS is not -(-ENOSYS)

[Rich Felker <dalias@libc.org>]

On Wed, Mar 11, 2020 at 10:08:11PM +0100, Andreas Dröscher wrote:
> Am 11.03.20 um 03:18 schrieb Rich Felker:
> >On Wed, Mar 11, 2020 at 03:08:22AM +0100, Andreas Dröscher wrote:
> >>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?
> 
> I've reverted 604f8d3d8b08ee4f548de193050ef93a7753c2e0 and additionally
> replaced all:
> return r7 ? -r2 : r2;
> with
> return (r7 && r2 > 0) ? -r2 : r2;
> 
> My software stack (built with OE-Core Zeus) now works almost flawlessly.
> Some Daemons have hiccups but those most likely come from source
> that expects syscalls to always succeed and on my system they are
> simply missing.
> 
> Thank you for your helping to sort this out.
> 
> You asked about n32/n64. I am not familiar with more modern MIPS Architectures.
> Therefore I can't give any informed answer. I found some documentation:
> https://www.linux-mips.org/wiki/Syscall but it does not give a
> definitive answer. It just points towards "all 3 mips are effected
> by the ordering requirement".

I'm posting a patch series now.

Rich