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 384 invoked from network); 10 Mar 2020 21:10:31 -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; 10 Mar 2020 21:10:31 -0000 Received: (qmail 30049 invoked by uid 550); 10 Mar 2020 21:10:28 -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 30019 invoked from network); 10 Mar 2020 21:10:27 -0000 To: musl@lists.openwall.com From: =?UTF-8?Q?Andreas_Dr=c3=b6scher?= Message-ID: Date: Tue, 10 Mar 2020 22:10:15 +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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: de-CH X-Mime-Autoconverted: from 8bit to 7bit by courier 1.0 Subject: [musl] mips32 little endian -ENOSYS is not -(-ENOSYS) Hi I'm building a new toolchain for a very old hardware with a very old Linux Kernel (2.6.20). The CPU is a Alchemy (now AMD) AU1100 (production was discontinued). Obviously the Kernel lacks a lot of the modern system calls. I however expect the general system call interface to be consistent. Moreover, musl has fallbacks for many system-calls in place, kudos! However, the fallback is never triggered. I will present the issue on one example (epoll): excerpt from src/linux/epoll.c: int epoll_create1(int flags) { int r = __syscall(SYS_epoll_create1, flags); #ifdef SYS_epoll_create if (r==-ENOSYS && !flags) r = __syscall(SYS_epoll_create, 1); #endif return __syscall_ret(r); } If r is -89 (negative ENOSYS) the fallback is triggered else the result is returned as it is. However, in my case __syscall returnes 89 (positive ENOSYS). I've tracked the return into the kernel and there the negative value is returned. The Kernel additionally sets r7 to 1. excerpt from arch/mips/syscall_arch.h: static inline long __syscall1(long n, long a) { register long r4 __asm__("$4") = a; register long r7 __asm__("$7"); register long r2 __asm__("$2") = n; __asm__ __volatile__ ( "syscall" : "+r"(r2), "=r"(r7) : "r"(r4) : SYSCALL_CLOBBERLIST, "$8", "$9", "$10"); return r7 ? -r2 : r2; } I assume the "bug" is triggered by __syscall1 If r7 is set it will change the sign of r2. I can patch that by replacing: return r7 ? -r2 : r2; with return (r7 && r2 > 0) ? -r2 : r2; However I've no idea if I'm triggering any side effects or if I selected the wrong implementation for my architecture. Any suggestions are appreciated. ~Andreas