[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200311213522.GI11469@brightrain.aerifal.cx>
Date: Wed, 11 Mar 2020 17:35:22 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: mips32 little endian -ENOSYS is not -(-ENOSYS)
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".
OK, here's the kernel commit that changed it:
8f5a00eb422ed86e77bb8f67e08b9fe6d30f679a. This was a lot of work to
find, since the reference to it from a later referred to it by a hash
it had in the linux-mips git repo which has since been deleted and
doesn't turn up at all on searches.
So it looks like all 3 variants were affected. This means I'll need to
evaluate reverting the change for the others too, make sure there was
no other change that needs to be kept, and then applying your patch
afterwards.
I'll try to get this done asap. Let me know if you find anything else
interesting that looks like it's still broken after reverting and
applying your patch.
Also, this regression in the final 1.1.x series might justify a 1.1.25
release at some point.
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.
