public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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: Thu, 29 Jun 2023 22:17:50 +0800	[thread overview]
Message-ID: <CAKcpw6W+w4kQOAZRBnZQJC51A95bwmbzuN7kq4uU+gWNzQid8g@mail.gmail.com> (raw)
In-Reply-To: <CAKcpw6VgXDux77Sh+-aPUbfSUorgAoA3UkQtM-PGcBhsf0Dqsw@mail.gmail.com>

YunQiang Su <wzssyqa@gmail.com> 于2023年6月19日周一 18:43写道:
>
> 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.
> >
>
> 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 <completed.0>:
>         ...
> 0000000000011040 <bar>:
>         ...
>
> objdump -D on mips32el:
> Disassembly of section .bss:
> 00010a70 <completed.1>:
>    10a70:       00000000        nop
> 00010a74 <dtor_idx.0>:
>         ...
> 00010a80 <bar>:
>         ...
>
> 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="CONSTANT (COMMONPAGESIZE)"
> -INITIAL_READONLY_SECTIONS="
> +INITIAL_READONLY_SECTIONS=
> +if test -z "${CREATE_SHLIB}"; then
> +  INITIAL_READONLY_SECTIONS=".interp       ${RELOCATING-0} : { *(.interp) }"
> +fi
> +INITIAL_READONLY_SECTIONS="${INITIAL_READONLY_SECTIONS}
>    .MIPS.abiflags      ${RELOCATING-0} : { *(.MIPS.abiflags) }
>    .MIPS.xhash      ${RELOCATING-0} : { *(.MIPS.xhash) }
>    .MIPS.options : { *(.MIPS.options) }
> ```
>

@Maciej W. Rozycki Any idea about this change?
Will it cause some other problems?

> > > 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
>
>
>
> --
> YunQiang Su



-- 
YunQiang Su

  parent reply	other threads:[~2023-06-29 14:18 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 [this message]
2023-06-20  2:58     ` Alan Modra
2023-07-03  4:00     ` YunQiang Su
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=CAKcpw6W+w4kQOAZRBnZQJC51A95bwmbzuN7kq4uU+gWNzQid8g@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).