From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 654D43858D28 for ; Mon, 19 Jun 2023 06:44:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 654D43858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1b520c77de0so11882095ad.0 for ; Sun, 18 Jun 2023 23:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687157061; x=1689749061; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=P0yudk1GBnvZUneZKL35L+QLyse+LA9vdSFikz3XBfc=; b=Lzn8/tcTYbA7JHdLmqx3H1rcXjsG3MXItxZIhu4gDex/mee/OgYhfmLKthTrnqlxpd /nUq4ChLwLA9SMtObFstJjlZLevRP5MDe0k8ehIVpFi9WoTngQi3SRT7KmUZ7Fmwv8JT ZyPq37gAXEWtFGB5SvrnW4dhMo1dqLAzkO4PPv9+KZ4MpafWGQaowjwGQMFMJAVY+yEo wtW7u44FAWTRG0HBDhbPubBVi5DI1PIzyvAmkjxGt+X87bwSb6nTlMJ3fmCiN+7yoyU6 f5JCZgCIhBYnGzQh0vPDuOYDV0C64u/1HmcCETOtVFUWVKq00GUvg8W7FAFx29MqobBZ jQaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687157061; x=1689749061; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=P0yudk1GBnvZUneZKL35L+QLyse+LA9vdSFikz3XBfc=; b=Rpx6tlwpud9h6vZwJ6h3AwFFNpugqoomfLBhbdzYlzD3iGKnpHLojNj6brYuavuddR 9YQizyipq7b1GfVjpiMM4MFpWM6D+tFHfA1dJ1MeAr+uGcfAtRe13CWoSKlIJdXmb3Ba wuc6IGCGh/ye07BIjlZlhihNGaLoMOmmEwYFYsJAQWIBA+ym8HvbA8/I0GzfJyM0FmTO o28olajn9lx6K8Qn0AIFr2TJUUR91/hd65q1jUjkkAAY+D+SoZ/yMvirbGcV4LBUJL/l Cy5ds8Jn9A7DNs5WIyGH5/X8I5ejqumS0jIpVwlFWRl4LouGRGP2p+r4bq+d/tx0HJQ7 5sLg== X-Gm-Message-State: AC+VfDxE4t4Bg369nWe0HSxtZ83WI1f+2xqCpySZ6o/uXA2EWq4OIsUd KBJIx0tf05++tDctB4EmEeg= X-Google-Smtp-Source: ACHHUZ4f4iI/w2hXwAQTpBaDzmh29tM+YGioWpfjs1uVJEahJUgUflgG/UVV5f3X00Llz/K6RW/AFg== X-Received: by 2002:a17:902:b197:b0:1b1:af8e:d31d with SMTP id s23-20020a170902b19700b001b1af8ed31dmr143943plr.40.1687157061120; Sun, 18 Jun 2023 23:44:21 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:4d08:cebd:d73f:b794]) by smtp.gmail.com with ESMTPSA id p14-20020a170902e74e00b001b39e866324sm15899413plf.306.2023.06.18.23.44.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Jun 2023 23:44:20 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id DAE5B114091D; Mon, 19 Jun 2023 16:14:17 +0930 (ACST) Date: Mon, 19 Jun 2023 16:14:17 +0930 From: Alan Modra To: YunQiang Su Cc: binutils@sourceware.org, macro@orcam.me.uk, paul.hua.gm@gmail.com, jbeulich@suse.com Subject: Re: [PATCH v4 5/7] MIPS: Fix some ld testcases with compiler Message-ID: References: <20230616063412.1715024-1-yunqiang.su@cipunited.com> <20230616063412.1715024-6-yunqiang.su@cipunited.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230616063412.1715024-6-yunqiang.su@cipunited.com> X-Spam-Status: No, score=-3027.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi YunQiang Su, I thought I'd take a detailed look at your patch modifying the generic ELF tests for mips, despite not really being familiar enough with mips to properly review mips changes. Most of this review is not about details of the patch but rather questioning whether you have done the necessary analysis before xfailing tests. It is reasonable to xfail a test if for some reason a problem cannot be fixed, or even if a problem is too difficult to be fixed. On the other hand we don't want a clean testsuite result if there are problems that should be fixed. On Fri, Jun 16, 2023 at 02:34:10PM +0800, YunQiang Su wrote: > 1. config/default.exp: > use -mabi=32 not for -gnuabi64; > xfail_from_runlist: remove an element and mark it xfail. I dislike the use of xfail here. xfail should only be used after running a test, to record an expected fail. Don't use it when a test is not run. > 2. ld-elf/indirect.exp: xfail > indirect5a, indirect5b, indirect6a, indirect6b, > indirect5c, indirect5d, indirect6c, indirect6d. Can you explain why is it correct to xfail these for mips? The first four pass for me on mips-linux. Is there a reason why the last four must make "bar" dynamic on mips? > 3. ld-elf/pr23658-2: mips output is not common. The purpose of this test is to check the placement of orphan loaded note sections. These ought to be placed near the start of the first PT_LOAD segment, so that they can be accessed by the kernel without reading many disk pages. Ideally they would be placed in the same page as the file header. This isn't happening for mips64, and I see the standard scripts don't even mention .interp, a section that also should be placed near the start of the first PT_LOAD. Why not?! > 4. ld-elf/shared.exp: non-run on mips: Build libpr16496b.so. OK, seems like we will actually generate a correct .so here for mips, so not much is lost by not running the testcase for mips. > 5. ld-elfvers/vers.exp: > xfail vers4, vers4b; I see a ld segfault in _bfd_mips_elf_generic_reloc due to symbol->section->output_section being NULL prior to this patch series. I'd hope that someone making changes to the testsuite would have seen this, and not ignored it. No one expects you to make linking non-native object files work, but not segfaulting it fairly important. > no-run on mips: vers24a, vers24b, vers24c. OK, fair enough. Mips is different enough that it isn't expected to pass these tests. > 6. ld-gc/gc.exp: add -KPIC into asflags for pr13683, pr14265, pr19161. OK. > 7. ld-mips-elf/mips-elf.exp: > use noarch for mips16-local-stubs-1, since it use -mips4. I'll leave this for the mips maintainers to OK. > 8. ld-plugin/lto.exp: > no-run on mips/linux: PR ld/12982; Please add a comment to lto.exp as to why mips requires an executable stack. > add -KPIC into asflags for lto-3r, lto-5r, PR ld/19317 (2); OK. > xfail PR ld/15323 (4), PR ld/19317 (3). Please explain why the lto plugin won't handle the objects. > 9. ld-plugin/plugin.exp: xfail > plugin claimfile lost symbol, > plugin claimfile replace symbol, > plugin claimfile replace symbol, > plugin claimfile lost symbol with source, > plugin claimfile replace symbol with source, > plugin claimfile resolve symbol with source, > plugin 2 with source lib, > load plugin 2 with source, > plugin 3 with source lib, > load plugin 3 with source. These all pass on mips-linux, and on mips64-linux. Why disable them? Yes, I see fails on mips64-linux-gnuabi64 but that looks like a gcc problem to me. > 11. ld-selective/selective.exp: add -fno-PIC, which is needed for -mno-abicalls. OK. > 12. ld-shared/shared.exp: xfail shared (non PIC), shared (PIC main, non PIC so). OK, and thanks for tweaking the xcoff test message. -- Alan Modra Australia Development Lab, IBM