[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200320163456.GB11469@brightrain.aerifal.cx>
Date: Fri, 20 Mar 2020 12:34:56 -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 07:08:48PM -0400, Rich Felker wrote:
> 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.
I've pushed a version of this upstream now, a long with a lot of other
commits that had backed up in my queue. Please let me know if this
does or doesn't fix the issues with mips on old kernels.
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.
