From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 18549 invoked from network); 11 Mar 2020 21:08:27 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 11 Mar 2020 21:08:27 -0000 Received: (qmail 3820 invoked by uid 550); 11 Mar 2020 21:08:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3802 invoked from network); 11 Mar 2020 21:08:23 -0000 To: musl@lists.openwall.com References: <20200311005553.GE11469@brightrain.aerifal.cx> <20200311014039.GF11469@brightrain.aerifal.cx> <5a45c0f9-21de-6649-d4d9-3d0804c3ca0e@droescher.ch> <20200311021808.GG11469@brightrain.aerifal.cx> From: =?UTF-8?Q?Andreas_Dr=c3=b6scher?= Message-ID: Date: Wed, 11 Mar 2020 22:08:11 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200311021808.GG11469@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-CH Content-Transfer-Encoding: 8bit Subject: Re: [musl] mips32 little endian -ENOSYS is not -(-ENOSYS) 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