From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCF4FC4361B for ; Wed, 16 Dec 2020 09:47:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7EABB2311B for ; Wed, 16 Dec 2020 09:47:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725940AbgLPJrQ (ORCPT ); Wed, 16 Dec 2020 04:47:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725890AbgLPJrP (ORCPT ); Wed, 16 Dec 2020 04:47:15 -0500 Received: from orcam.me.uk (unknown [IPv6:2001:4190:8020::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 70A4FC0613D6; Wed, 16 Dec 2020 01:46:35 -0800 (PST) Received: from bugs.linux-mips.org (eddie.linux-mips.org [IPv6:2a01:4f8:201:92aa::3]) by orcam.me.uk (Postfix) with ESMTPS id 8A9112BE0EC; Wed, 16 Dec 2020 09:46:33 +0000 (GMT) Date: Wed, 16 Dec 2020 09:44:53 +0000 (GMT) From: "Maciej W. Rozycki" To: Al Viro cc: Linus Torvalds , Thomas Bogendoerfer , Linux Kernel Mailing List , the arch/x86 maintainers , linux-mips@vger.kernel.org, Randy Dunlap Subject: Re: [PATCHSET] saner elf compat In-Reply-To: <20201216030154.GL3579531@ZenIV.linux.org.uk> Message-ID: References: <20201203214529.GB3579531@ZenIV.linux.org.uk> <20201203230336.GC3579531@ZenIV.linux.org.uk> <20201216030154.GL3579531@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Wed, 16 Dec 2020, Al Viro wrote: > > It may be worth pushing through GDB's gdb.threads/tls-core.exp test case, > > making sure no UNSUPPORTED results have been produced due to resource > > limits preventing a core from being dumped (and no FAILs, of course), with > > o32/n32 native GDB. This should guarantee our output is still as expected > > by an interpreter. Sadly I'm currently not set up for such testing though > > eventually I mean to. > > Umm... What triple does one use for n32 gdb? I don't think there's a standardised one, just configure with CC/CXX set for n32 compilation, e.g.: $ /path/to/configure CC="gcc -mabi=n32" CXX="g++ -mabi=n32" (and any other options set as usually). This has to be with CC/CXX rather than CFLAGS/CXXFLAGS so that it is guaranteed to be never overridden with any logic that might do any fiddling with compilation options. This will set up the test suite accordingly. NB this may already be the compiler's default, depending on how it was configured, i.e. if `--with-abi=n32' was used, in which case no extra options will be required. I don't know if any standard MIPS distribution does it though; 64-bit MIPS/Debian might. This will be reported with `gcc --help -v', somewhere along the way. Let me know if there are issues with this approach. Maciej