From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Maciej W. Rozycki" Subject: Re: [PATCH v3 0/6] mips: system call table generation support Date: Fri, 7 Dec 2018 14:33:17 +0000 (GMT) Message-ID: References: <1543481016-18500-1-git-send-email-firoz.khan@linaro.org> <20181205063436.kzxgnvgexcgq572k@pburton-laptop> <87mupiikzy.fsf@oldenburg2.str.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Return-path: Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23992798AbeLGOdRhC0sC (ORCPT + 1 other); Fri, 7 Dec 2018 15:33:17 +0100 In-Reply-To: <87mupiikzy.fsf@oldenburg2.str.redhat.com> Sender: linux-kernel-owner@vger.kernel.org To: Florian Weimer Cc: Joseph Myers , Paul Burton , Firoz Khan , "open list:RALINK MIPS ARCHITECTURE" , Ralf Baechle , James Hogan , Greg Kroah-Hartman , Philippe Ombredanne , Thomas Gleixner , Kate Stewart , y2038 Mailman List , Arnd Bergmann , Linux Kernel Mailing List , Linux-Arch , Deepa Dinamani , Marcin Juszkiewicz , libc-alpha@sourceware.org List-Id: linux-arch.vger.kernel.org On Thu, 6 Dec 2018, Florian Weimer wrote: > > I seem to remember having to take extra care with how the three MIPS ABIs > > wire the syscalls to get it right in glibc, but I take it then this has > > been now addressed reliably enough for the glibc not to care how exactly > > has been arranged. > > This is a fairly recent change (commit > 2dba5ce7b8115d6a2789bf279892263621088e74, ": Use an > arch-independent system call list on Linux", first release with it is > glibc 2.27). This patch is quite backportable; we have put it into our > 2.17-derived glibc, and the upstream work was originally driven by > downstream ordering requirements of kernel header and glibc builds. > Glad to see it's useful elsewhere. Thanks for the pointer, and the work you have done to make this more robust; it was that that I missed. > The test retains the old -based macro extraction for > testing purposes, but it needs that only for the actual target > architecture and only the *names*, so it's easy to implement. Before > that, the generation would have to carefully take into account multiple > sub-targets (i386/x86-64/x32 is one of the more complicated scenarios). > Presumably, you saw problem with that part. Yeah, the MIPS o32/n64/n32 ABI set is a corresponding situation, except that somewhat longer-lived as we've had support for these three ABIs since 2001, including the ability to concurrently run user executables built for any of these ABIs under a single 64-bit Linux kernel. Maciej From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eddie.linux-mips.org ([148.251.95.138]:42132 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726029AbeLGOdU (ORCPT ); Fri, 7 Dec 2018 09:33:20 -0500 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23992798AbeLGOdRhC0sC (ORCPT + 1 other); Fri, 7 Dec 2018 15:33:17 +0100 Date: Fri, 7 Dec 2018 14:33:17 +0000 (GMT) From: "Maciej W. Rozycki" Subject: Re: [PATCH v3 0/6] mips: system call table generation support In-Reply-To: <87mupiikzy.fsf@oldenburg2.str.redhat.com> Message-ID: References: <1543481016-18500-1-git-send-email-firoz.khan@linaro.org> <20181205063436.kzxgnvgexcgq572k@pburton-laptop> <87mupiikzy.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-arch-owner@vger.kernel.org List-ID: To: Florian Weimer Cc: Joseph Myers , Paul Burton , Firoz Khan , "open list:RALINK MIPS ARCHITECTURE" , Ralf Baechle , James Hogan , Greg Kroah-Hartman , Philippe Ombredanne , Thomas Gleixner , Kate Stewart , y2038 Mailman List , Arnd Bergmann , Linux Kernel Mailing List , Linux-Arch , Deepa Dinamani , Marcin Juszkiewicz , libc-alpha@sourceware.org Message-ID: <20181207143317.lDJD3mzxl9MeDEeeddqi63dFFF_aYgeCE6f3M3RiXvw@z> On Thu, 6 Dec 2018, Florian Weimer wrote: > > I seem to remember having to take extra care with how the three MIPS ABIs > > wire the syscalls to get it right in glibc, but I take it then this has > > been now addressed reliably enough for the glibc not to care how exactly > > has been arranged. > > This is a fairly recent change (commit > 2dba5ce7b8115d6a2789bf279892263621088e74, ": Use an > arch-independent system call list on Linux", first release with it is > glibc 2.27). This patch is quite backportable; we have put it into our > 2.17-derived glibc, and the upstream work was originally driven by > downstream ordering requirements of kernel header and glibc builds. > Glad to see it's useful elsewhere. Thanks for the pointer, and the work you have done to make this more robust; it was that that I missed. > The test retains the old -based macro extraction for > testing purposes, but it needs that only for the actual target > architecture and only the *names*, so it's easy to implement. Before > that, the generation would have to carefully take into account multiple > sub-targets (i386/x86-64/x32 is one of the more complicated scenarios). > Presumably, you saw problem with that part. Yeah, the MIPS o32/n64/n32 ABI set is a corresponding situation, except that somewhat longer-lived as we've had support for these three ABIs since 2001, including the ability to concurrently run user executables built for any of these ABIs under a single 64-bit Linux kernel. Maciej