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

["Andreas Dröscher" <musl@bugfree.ch>]

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".

Andreas