From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 481903858D28 for ; Mon, 19 Jun 2023 10:43:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 481903858D28 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-x62a.google.com with SMTP id d9443c01a7336-1b52bf6e66aso12928995ad.3 for ; Mon, 19 Jun 2023 03:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687171397; x=1689763397; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lIVvQ85rXTFgLwyq2tS/GBbLCRN7ZrLT9uzpX3UOmZI=; b=XadjZUzXfBQ8nDUhmWsgkjYcPVX+WE5JdQNOhHG3A+98EvGV/U5jIQUxfqev++R8+Q qzyV2nMZnm7zU7HnHWQlemjk8ve0HKx8j5vvtLPlOOtKJ/FYELsAFVGeVWOtNtkstPRY Tk24NAxvHMDuvHCgnCztsTJ9+HON4RFMvyYUhq40OP5EcNPM3n0Nhe7OmrRiWRgM1FSX iMhaHyZ23Tnn3vXrewpG7/b9MLiXv5LABiv2R++qtJaT7BrC8wGqFTxovoyRFiyc9sFv 1c5fQ+GezU8VoYcVYPwMzOXsFC6DqkuuaG+VYn1YS9aa6klyZhtnUa8i9SZBQ++cXJ5Q q3SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687171397; x=1689763397; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lIVvQ85rXTFgLwyq2tS/GBbLCRN7ZrLT9uzpX3UOmZI=; b=Ntij2EzOFXuzbpqHpyBdID6NcMFLMTwRdmBBWyLMaFTMNu2sBgWhNIfG8N1Ajccbf7 VA3v9jE90P4IYQ1HVHCCpmWfXeNTNOCiUkweJfIRe+C3o9sEtSrzgwUsRabktPatdMTV jrPJyORI5kPUCB+CuiAvtDlnLIWTk6Gd80tOiNkPTr60kNvE9GJYRwcqMJzDXvLskIUJ HMVKsO4VxZY1G178jVpIkuDWjGMJqnLss2zuVKZ2rwcG13FgXP8Vn6644GhAxJpUcJWS MMMdXvhok5dOaFBiQqqrudMBxeTqHNd4MQ9NdmIHkA1El49ZY9T8bwMc0xHzu1Ag/QkD RN0g== X-Gm-Message-State: AC+VfDzIyNd8rhaq3WYgJ1I26y/K7UWpvc/ouIBytouuiLfH8VOn1eys /Pg/Twh+HKdvtjhSD+K0RkkGTM3AZW/0OhT1CL8= X-Google-Smtp-Source: ACHHUZ75h4EIJdcp0ePkyBdNMUAl+P7sSTpoSAHzaqM7oJl7san4oVuHsNoF5Wi0A6FpqRR5trmklEmr6f8sFnn9OP0= X-Received: by 2002:a17:903:2444:b0:1b1:d8ce:73cb with SMTP id l4-20020a170903244400b001b1d8ce73cbmr567549pls.59.1687171397055; Mon, 19 Jun 2023 03:43:17 -0700 (PDT) MIME-Version: 1.0 References: <20230616063412.1715024-1-yunqiang.su@cipunited.com> <20230616063412.1715024-6-yunqiang.su@cipunited.com> In-Reply-To: From: YunQiang Su Date: Mon, 19 Jun 2023 18:43:05 +0800 Message-ID: Subject: Re: [PATCH v4 5/7] MIPS: Fix some ld testcases with compiler To: Alan Modra Cc: YunQiang Su , binutils@sourceware.org, macro@orcam.me.uk, paul.hua.gm@gmail.com, jbeulich@suse.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,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: Alan Modra via Binutils =E4=BA=8E2023=E5=B9=B46= =E6=9C=8819=E6=97=A5=E5=91=A8=E4=B8=80 14:44=E5=86=99=E9=81=93=EF=BC=9A > > 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=3D32 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. > Maybe, kfail is better? > > 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? > Do you have a cross compiler installed? These tests won't even try to run without a corresponding cross compiler installed. The real problem seems due to the output of nm -D. objdump -D on aarch64: Disassembly of section .bss: 0000000000011038 : ... 0000000000011040 : ... objdump -D on mips32el: Disassembly of section .bss: 00010a70 : 10a70: 00000000 nop 00010a74 : ... 00010a80 : ... While the outputs of NM -D are different. Let me have a more dig about it. > > 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?! > Oh, yes. This tiny patch can solve this problem. I have no idea why it doesn't like that. Maybe somebody forgot this in history. @Maciej W. Rozycki Any ideas? ``` diff --git a/ld/emulparams/elf64bmip-defs.sh b/ld/emulparams/elf64bmip-defs= .sh index 4165f51e9e5..19d782d8e7a 100644 --- a/ld/emulparams/elf64bmip-defs.sh +++ b/ld/emulparams/elf64bmip-defs.sh @@ -1,6 +1,10 @@ source_sh ${srcdir}/emulparams/elf32bmipn32-defs.sh COMMONPAGESIZE=3D"CONSTANT (COMMONPAGESIZE)" -INITIAL_READONLY_SECTIONS=3D" +INITIAL_READONLY_SECTIONS=3D +if test -z "${CREATE_SHLIB}"; then + INITIAL_READONLY_SECTIONS=3D".interp ${RELOCATING-0} : { *(.interp= ) }" +fi +INITIAL_READONLY_SECTIONS=3D"${INITIAL_READONLY_SECTIONS} .MIPS.abiflags ${RELOCATING-0} : { *(.MIPS.abiflags) } .MIPS.xhash ${RELOCATING-0} : { *(.MIPS.xhash) } .MIPS.options : { *(.MIPS.options) } ``` > > 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. > Should we add a pr16496b-mips.od file? > > 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. > Maybe we should grep segfault in the log files on our CI system. I will try to do so. FYI: I run my test here: https://oss.cipunited.com/ci/job/Toolchain/job/binutils-cross/ > > 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. > Do you really install C/C++ compilers? > > 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 --=20 YunQiang Su