From: YunQiang Su <wzssyqa@gmail.com>
To: Alan Modra <amodra@gmail.com>
Cc: YunQiang Su <yunqiang.su@cipunited.com>,
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
Date: Mon, 3 Jul 2023 12:00:13 +0800 [thread overview]
Message-ID: <CAKcpw6WOL+tNb4J3WYbP-=QH=zeDm=q2iMZR4ZO1P7+tpJyBxA@mail.gmail.com> (raw)
In-Reply-To: <ZI/5QTX+a+OXPyBa@squeak.grove.modra.org>
Alan Modra via Binutils <binutils@sourceware.org> 于2023年6月19日周一 14:44写道:
>
> 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.
>
Thank you. It seems really a bug: ld -r cannot work with LTO objects.
I am trying to find the real problem.
> > 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
--
YunQiang Su
next prev parent reply other threads:[~2023-07-03 4:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-16 6:34 [PATCH v4 0/7] Some MIPS changes and testsuite fixes YunQiang Su
2023-06-16 6:34 ` [PATCH v4 1/7] MIPS: Gas: alter 64 or 32 for mipsisa triples if march is implicit YunQiang Su
2023-06-29 10:12 ` YunQiang Su
2023-06-16 6:34 ` [PATCH v4 2/7] MIPS: Set r6 as default arch if vendor is img YunQiang Su
2023-06-16 6:34 ` [PATCH v4 3/7] MIPS: Fix r6 testsuites YunQiang Su
2023-06-16 6:34 ` [PATCH v4 4/7] MIPS: Fix -gnuabi64 testsuite YunQiang Su
2023-06-16 6:34 ` [PATCH v4 5/7] MIPS: Fix some ld testcases with compiler YunQiang Su
2023-06-19 6:44 ` Alan Modra
2023-06-19 10:43 ` YunQiang Su
2023-06-20 0:00 ` Alan Modra
2023-06-20 1:40 ` YunQiang Su
2023-06-20 2:34 ` Alan Modra
2023-06-20 3:17 ` YunQiang Su
2023-06-20 3:57 ` Alan Modra
2023-06-21 5:05 ` YunQiang Su
2023-06-21 10:53 ` YunQiang Su
2023-06-21 10:59 ` Xi Ruoyao
2023-06-21 11:03 ` YunQiang Su
2023-06-29 14:17 ` YunQiang Su
2023-06-20 2:58 ` Alan Modra
2023-07-03 4:00 ` YunQiang Su [this message]
2023-06-16 6:34 ` [PATCH v4 6/7] MIPS: Disable fix-rm7000-2 and llpscp-64 if not has_newabi YunQiang Su
2023-06-16 6:34 ` [PATCH v4 7/7] MIPS: Fix Irix gas testcases YunQiang Su
2023-08-15 4:40 ` YunQiang Su
2023-08-15 6:13 ` Jan Beulich
2023-08-15 10:14 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKcpw6WOL+tNb4J3WYbP-=QH=zeDm=q2iMZR4ZO1P7+tpJyBxA@mail.gmail.com' \
--to=wzssyqa@gmail.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.com \
--cc=macro@orcam.me.uk \
--cc=paul.hua.gm@gmail.com \
--cc=yunqiang.su@cipunited.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).