New failures for the mips64el-openbsd target

New failures for the mips64el-openbsd target

[Nick Clifton]

Hi Maciej,

  I am seeing a large number of new test failures for the mips64el-openbsd
  target:

  GAS REGRESSION: forward expression   
  GAS REGRESSION: assignment tests   
  GAS REGRESSION: gas/all/none    
  GAS REGRESSION: macro test 2  
  GAS REGRESSION: macro irp   
  GAS REGRESSION: macro rept   
  GAS REGRESSION: nested irp/irpc/rept   
  GAS REGRESSION: macro vararg   
  GAS REGRESSION: Compact EH EB #1 with
  GAS REGRESSION: Compact EH EB #2 with
  GAS REGRESSION: Compact EH EB #3 with
  GAS REGRESSION: Compact EH EB #4 with
  GAS REGRESSION: Compact EH EB #5 with
  GAS REGRESSION: Compact EH EB #6 with
  GAS REGRESSION: Compact EH EL #1 with
  GAS REGRESSION: Compact EH EL #2 with
  GAS REGRESSION: Compact EH EL #3 with
  GAS REGRESSION: Compact EH EL #4 with
  GAS REGRESSION: Compact EH EL #5 with
  GAS REGRESSION: Compact EH EL #6 with
  GAS REGRESSION: Compact EH EL #7 with
  GAS REGRESSION: MIPS RM7000 workarounds test 2
  GAS REGRESSION: mips jalx   
  GAS REGRESSION: .set arch=FOO   
  GAS REGRESSION: ST Microelectronics Loongson-2F workarounds of
  GAS REGRESSION: ST Microelectronics Loongson-2F workarounds of
  GAS REGRESSION: MIPS DSP ASE for MIPS64
  GAS REGRESSION: gas/mips/align2
  GAS REGRESSION: gas/mips/align2-el    
  GAS REGRESSION: Locally-resolvable PC-relative code references 
  GAS REGRESSION: Paired LL/SC for mips64r6 (mips64r6)
  LD REGRESSION: ld-elf/eh5    
  LD REGRESSION: ld-elf/group3a    
  LD REGRESSION: ld-elf/group3b    
  LD REGRESSION: Place orphan sections (map file
  LD REGRESSION: ld-elf/orphan-region    
  LD REGRESSION: ld-elf/orphan    
  LD REGRESSION: MIPS jalx-1   
  LD REGRESSION: MIPS JALX to unaligned symbol
  LD REGRESSION: MIPS16 JALX to unaligned symbol
  LD REGRESSION: microMIPS JALX to unaligned symbol
  LD REGRESSION: JAL overflow 2  
  LD REGRESSION: MIPS16 interlinking for local functions
  LD REGRESSION: ld-mips-elf/attr-gnu-4-10    
  LD REGRESSION: overlay size (map file check)
  LD REGRESSION: overlay size   
  BIN REGRESSION: readelf -S bintest  
  BIN REGRESSION: readelf -r bintest  

  I do not know if these are related to your recent gas testuite fix
  (2b462da34de977f953a778afa0cb55e3286ece3d), but would you mind
  checking please ?  If you cannot reproduce the problems, then it is
  probably an issue at my end - maybe I need to rerun the configure
  script or something like that - and I will investigate some more.

Cheers
  Nick
  

Re: New failures for the mips64el-openbsd target

[Maciej W. Rozycki]

Hi Nick,

>   I do not know if these are related to your recent gas testuite fix
>   (2b462da34de977f953a778afa0cb55e3286ece3d), but would you mind
>   checking please ?  If you cannot reproduce the problems, then it is
>   probably an issue at my end - maybe I need to rerun the configure
>   script or something like that - and I will investigate some more.

 It may well be that one of the YunQiang Su's patches I have reverted 
brough these back; a regression from his earlier commit(s) anyway.

 I haven't run any verification on the reverts as I don't think there is 
any excuse for violating our policies and committing patches with no prior 
approval and/or with objections raised.  I think let's wait and see how 
YunQiang handles it, and if it turns out to be a failure, then I'll handle 
it one way or another (maybe his earlier commits need to be reverted too).

 NB YunQiang has been around long enough to know what our policies are and 
what the requirements are for good patch submissions.  Conversely the Sony 
Allegrex support was submitted by a newcomer and it was a perfect example 
of how a good submission looks like.  Sure it wasn't perfect, there were a 
couple of minor issues, but it was made with due dilligence and it was a 
pleasure to review.  So it's not that it cannot be done.

 FWIW,

  Maciej

Re: New failures for the mips64el-openbsd target

[YunQiang Su]

Maciej W. Rozycki <macro@orcam.me.uk> 于2023年6月15日周四 22:43写道：
>
> Hi Nick,
>
> >   I do not know if these are related to your recent gas testuite fix
> >   (2b462da34de977f953a778afa0cb55e3286ece3d), but would you mind
> >   checking please ?  If you cannot reproduce the problems, then it is
> >   probably an issue at my end - maybe I need to rerun the configure
> >   script or something like that - and I will investigate some more.
>
>  It may well be that one of the YunQiang Su's patches I have reverted
> brough these back; a regression from his earlier commit(s) anyway.
>

I run a test with the below commit, because the next commit of it is
my first commit to binutils.

commit 2e6be59c8de57c32260771ac5307968d18793a0a (HEAD -> xxxxx)
Author: Nick Clifton <nickc@redhat.com>
Date:   Thu Jul 25 13:05:27 2019 +0100

    Stop an illegal memory access by readelf when parsing a corrupt
MIPS binary file.

            PR 24837
            * readelf.c (process_mips_specific): Check for buffer overflow
            before reading reginfo information.

The test fails do exist with this commit.

So I think that it is a long time problem, and in fact my recent
commits resolve them.

>  I haven't run any verification on the reverts as I don't think there is
> any excuse for violating our policies and committing patches with no prior
> approval and/or with objections raised.  I think let's wait and see how
> YunQiang handles it, and if it turns out to be a failure, then I'll handle
> it one way or another (maybe his earlier commits need to be reverted too).
>

I will resend my patchset, of course with more code style checks.

>  NB YunQiang has been around long enough to know what our policies are and
> what the requirements are for good patch submissions.  Conversely the Sony
> Allegrex support was submitted by a newcomer and it was a perfect example
> of how a good submission looks like.  Sure it wasn't perfect, there were a
> couple of minor issues, but it was made with due dilligence and it was a
> pleasure to review.  So it's not that it cannot be done.
>
>  FWIW,
>
>   Maciej



-- 
YunQiang Su

Re: New failures for the mips64el-openbsd target

[Alan Modra]

On Thu, Jun 15, 2023 at 03:43:14PM +0100, Maciej W. Rozycki wrote:
> Hi Nick,
> 
> >   I do not know if these are related to your recent gas testuite fix
> >   (2b462da34de977f953a778afa0cb55e3286ece3d), but would you mind
> >   checking please ?  If you cannot reproduce the problems, then it is
> >   probably an issue at my end - maybe I need to rerun the configure
> >   script or something like that - and I will investigate some more.
> 
>  It may well be that one of the YunQiang Su's patches I have reverted 
> brough these back; a regression from his earlier commit(s) anyway.

Hi Maciej,
The testsuite fixes that you've reverted were not just fixing
regressions from earlier commits.

>  I haven't run any verification on the reverts as I don't think there is 
> any excuse for violating our policies and committing patches with no prior 
> approval and/or with objections raised.

Yes, you're well within your rights to revert the patches.

>  I think let's wait and see how YunQiang handles it,

Can I suggest you post a list of mips targets you'd like to be
regression tested with any mips specific changes?

FWIW, I test mips-linux-gnu, mips-sgi-irix6, mips-vxworks,
mips64-linux-gnuabi64, mips64-openbsd, mips64el-openbsd,
mipsel-linux-gnu, mipsisa32el-linux-gnu, mipsisa32r2el-elf, and
mipstx39-elf as part of the set of targets that I check regularly in
order to stop me breaking everything.  I also have a full cross
toolchain installed for mips64-linux-gnuabi64 and mips-linux-gnu.
Even that limited set showed problems with YunQiang Su's patches.

Meanwhile, I'm going to correct the ld-elf/eh5 test for hppa64.

Commit 3c0afdb78988 regressed this test for hppa64, because the test
had been enabled for hppa64 in the time between the mips changes and
their reversion.  This patch isn't just a simple reapply, I recreated
the testsuite change by hand for hppa64: Two lines in eh5.d might need
further changes for mips.

diff --git a/ld/testsuite/ld-elf/eh5.d b/ld/testsuite/ld-elf/eh5.d
index ac571940d4a..d51b4809e94 100644
--- a/ld/testsuite/ld-elf/eh5.d
+++ b/ld/testsuite/ld-elf/eh5.d
@@ -24,14 +24,14 @@ Contents of the .eh_frame section:
 #?  DW_CFA_nop
 #?  DW_CFA_nop
 
-0+001[48] 0+0014 0+001[8c] FDE cie=0+0000 pc=.*
+0+001[48] 0+001[4c] 0+001[8c] FDE cie=0+0000 pc=.*
   DW_CFA_advance_loc: 4 to .*
   DW_CFA_def_cfa: r0(.*) ofs 16
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
 
-0+00(2c|30) 0+0014 0+0000 CIE
+0+00(2c|30|38) 0+0014 0+0000 CIE
   Version:               [13]
   Augmentation:          "zPR"
   Code alignment factor: .*
@@ -41,21 +41,21 @@ Contents of the .eh_frame section:
 
   DW_CFA_nop
 
-0+004[48] 0+0014 0+001c FDE cie=0+00(2c|30) pc=.*
+0+00(44|48|50) 0+001[4c] 0+001c FDE cie=0+00(2c|30|38) pc=.*
   DW_CFA_advance_loc: 4 to .*
   DW_CFA_def_cfa: r0(.*) ofs 16
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
 
-0+00(5c|60) 0+0014 0+006[04] FDE cie=0+0000 pc=.*
+0+00(5c|60|70) 0+001[4c] 0+00(60|64|74) FDE cie=0+0000 pc=.*
   DW_CFA_advance_loc: 4 to .*
   DW_CFA_def_cfa: r0(.*) ofs 16
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
 
-0+007[48] 0+001[8c] 0+0000 CIE
+0+00(74|78|90) 0+001[8c] 0+0000 CIE
   Version:               [13]
   Augmentation:          "zPLR"
   Code alignment factor: .*
@@ -71,7 +71,7 @@ Contents of the .eh_frame section:
 #?  DW_CFA_nop
 #?  DW_CFA_nop
 
-0+009[08] 0+001c 0+002[04] FDE cie=0+007[48] pc=.*
+0+00(90|98|b0) 0+00(1c|24) 0+002[04] FDE cie=0+00(74|78|90) pc=.*
   Augmentation data:     (ef be ad de 00 00 00 00|00 00 00 00 de ad be ef)
 
   DW_CFA_advance_loc: 4 to .*
@@ -80,7 +80,7 @@ Contents of the .eh_frame section:
   DW_CFA_nop
   DW_CFA_nop
 
-0+00b[08] 0+001[04] 0+0000 CIE
+0+00(b0|b8|d8) 0+001[04] 0+0000 CIE
   Version:               [13]
   Augmentation:          "zR"
   Code alignment factor: .*
@@ -94,7 +94,7 @@ Contents of the .eh_frame section:
 #?  DW_CFA_nop
 #?  DW_CFA_nop
 
-0+00(c4|d0) 0+001[04] 0+001[8c] FDE cie=0+00b[08] pc=.*
+0+00(c4|d0|f0) 0+001[048] 0+001[8c] FDE cie=0+00(b0|b8|d8) pc=.*
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
@@ -103,7 +103,7 @@ Contents of the .eh_frame section:
 #?  DW_CFA_nop
 #?  DW_CFA_nop
 
-0+00[de]8 0+0014 0+0000 CIE
+0+0(0d8|0e8|10c) 0+001[48] 0+0000 CIE
   Version:               [13]
   Augmentation:          "zPR"
   Code alignment factor: .*
@@ -112,15 +112,19 @@ Contents of the .eh_frame section:
   Augmentation data:     03 .. .. .. .. [01][bc]
 
   DW_CFA_nop
+#?  DW_CFA_nop
+#?  DW_CFA_nop
+#?  DW_CFA_nop
+#?  DW_CFA_nop
 
-0+0(0f|10)0 0+0014 0+001c FDE cie=0+00[de]8 pc=.*
+0+0(0f0|100|128) 0+001[4c] 0+00(1c|20) FDE cie=0+0(0d8|0e8|10c) pc=.*
   DW_CFA_advance_loc: 4 to .*
   DW_CFA_def_cfa: r0(.*) ofs 16
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
 
-0+01[01]8 0+001[04] 0+00(5c|64) FDE cie=0+00b[08] pc=.*
+0+01[014]8 0+001[048] 0+00(5c|64|74) FDE cie=0+00(b0|b8|d8) pc=.*
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
@@ -129,7 +133,7 @@ Contents of the .eh_frame section:
 #?  DW_CFA_nop
 #?  DW_CFA_nop
 
-0+01(1c|30) 0+001[8c] 0+0000 CIE
+0+01(1c|30|64) 0+001[8c] 0+0000 CIE
   Version:               [13]
   Augmentation:          "zPLR"
   Code alignment factor: .*
@@ -145,7 +149,7 @@ Contents of the .eh_frame section:
 #?  DW_CFA_nop
 #?  DW_CFA_nop
 
-0+01(38|50) 0+001c 0+002[04] FDE cie=0+01(1c|30) pc=.*
+0+01(38|50|80) 0+00(1c|24) 0+002[04] FDE cie=0+01(1c|30|64) pc=.*
   Augmentation data:     (ef be ad de 00 00 00 00|00 00 00 00 de ad be ef)
 
   DW_CFA_advance_loc: 4 to .*
@@ -154,7 +158,7 @@ Contents of the .eh_frame section:
   DW_CFA_nop
   DW_CFA_nop
 
-0+01(58|70) 0+0014 0+01(5c|74) FDE cie=0+0000 pc=.*
+0+01(58|70|a8) 0+001[4c] 0+01(5c|74|ac) FDE cie=0+0000 pc=.*
   DW_CFA_advance_loc: 4 to .*
   DW_CFA_def_cfa: r0(.*) ofs 16
   DW_CFA_nop
@@ -170,14 +174,14 @@ Contents of the .eh_frame section:
 #?  Augmentation data:     03 .. .. .. .. 1b
 #?  DW_CFA_nop
 
-0+01(70|88) 0+0014 0+0(01c|148|15c) FDE cie=0+0(02c|030|170) pc=.*
+0+01(70|88|c8) 0+001[4c] 0+0(01c|148|15c|194) FDE cie=0+0(02c|030|038|170) pc=.*
   DW_CFA_advance_loc: 4 to .*
   DW_CFA_def_cfa: r0(.*) ofs 16
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
 
-0+01(88|a0) 0+0014 0+01(8c|a4) FDE cie=0+0000 pc=.*
+0+01(88|a0|e8) 0+001[4c] 0+01(8c|a4|ec) FDE cie=0+0000 pc=.*
   DW_CFA_advance_loc: 4 to .*
   DW_CFA_def_cfa: r0(.*) ofs 16
   DW_CFA_nop
@@ -195,7 +199,7 @@ Contents of the .eh_frame section:
 #?  DW_CFA_nop
 #?  DW_CFA_nop
 
-0+01(a0|b8|d4) 0+001c 0+0(020|130|144) FDE cie=0+0(074|078|1b8) pc=.*
+0+0(1a0|1b8|1d4|208) 0+00(1c|24) 0+0(020|130|144|17c) FDE cie=0+0(074|078|090|1b8) pc=.*
   Augmentation data:     (ef be ad de 00 00 00 00|00 00 00 00 de ad be ef)
 
   DW_CFA_advance_loc: 4 to .*

-- 
Alan Modra
Australia Development Lab, IBM

Re: New failures for the mips64el-openbsd target

[Maciej W. Rozycki]

On Fri, 16 Jun 2023, YunQiang Su wrote:

> >  It may well be that one of the YunQiang Su's patches I have reverted
> > brough these back; a regression from his earlier commit(s) anyway.
> >
> 
> I run a test with the below commit, because the next commit of it is
> my first commit to binutils.
> 
> commit 2e6be59c8de57c32260771ac5307968d18793a0a (HEAD -> xxxxx)
> Author: Nick Clifton <nickc@redhat.com>
> Date:   Thu Jul 25 13:05:27 2019 +0100
> 
>     Stop an illegal memory access by readelf when parsing a corrupt
> MIPS binary file.
> 
>             PR 24837
>             * readelf.c (process_mips_specific): Check for buffer overflow
>             before reading reginfo information.
> 
> The test fails do exist with this commit.
> 
> So I think that it is a long time problem, and in fact my recent
> commits resolve them.

 Good.  Please post fixes then to regressions introduced with any changes 
of yours starting from commit 32f1c80375eb ("MIPS: support mips*64 as CPU 
and gnuabi64 as ABI") as a separate change (or multiple changes) from any 
fixes to pre-existing problems.  The more self-contained a change is the 
more straightforward to review it is.

 It's OK to fix regressions one by one with separate patches, or to only 
have an identical change bulk-applied across multiple files in a single 
patch.

 Overall changes that live in downstream repositories often have a long 
history behind them, which is not necessarily relevant at the upstream 
submission time.  Consequently they may have to be merged, split, and/or 
have bits and pieces moved between changes to make them consistent from 
the upstream code's point of view.  I've been through it myself across 
many projects and I am sure I'm no exception here.

 So please try and avoid submitting unrelated changes bundled together in
a single patch, and of course regression-test each individual change in a 
patch set as they are incrementally applied.

 Also please try and separate changes to the MIPS subset of the testsuites 
from ones to their generic part, as those usually need to be reviewed by a 
general maintainer (unless say you're just about to remove a MIPS XFAIL), 
and also need to be verified across non-MIPS targets.

> >  I haven't run any verification on the reverts as I don't think there is
> > any excuse for violating our policies and committing patches with no prior
> > approval and/or with objections raised.  I think let's wait and see how
> > YunQiang handles it, and if it turns out to be a failure, then I'll handle
> > it one way or another (maybe his earlier commits need to be reverted too).
> >
> 
> I will resend my patchset, of course with more code style checks.

 I look forward to that, thank you.

  Maciej

Re: New failures for the mips64el-openbsd target

[Maciej W. Rozycki]

On Fri, 16 Jun 2023, Alan Modra wrote:

> >  It may well be that one of the YunQiang Su's patches I have reverted 
> > brough these back; a regression from his earlier commit(s) anyway.
> 
> Hi Maciej,
> The testsuite fixes that you've reverted were not just fixing
> regressions from earlier commits.

 I was aware there could be fallout from the revert, especially as there 
was a conflict with a change of yours in a generic test case, which I 
resolved by only leaving your change in.  This is an unfortunate 
consequence of having unrelated changes bundled together in the original 
commit.

> >  I think let's wait and see how YunQiang handles it,
> 
> Can I suggest you post a list of mips targets you'd like to be
> regression tested with any mips specific changes?
> 
> FWIW, I test mips-linux-gnu, mips-sgi-irix6, mips-vxworks,
> mips64-linux-gnuabi64, mips64-openbsd, mips64el-openbsd,
> mipsel-linux-gnu, mipsisa32el-linux-gnu, mipsisa32r2el-elf, and
> mipstx39-elf as part of the set of targets that I check regularly in
> order to stop me breaking everything.  I also have a full cross
> toolchain installed for mips64-linux-gnuabi64 and mips-linux-gnu.
> Even that limited set showed problems with YunQiang Su's patches.

 Here's my current set of MIPS targets:

mips-elf mips-img-elf mips-mti-elf mips-sde-elf mips-freebsd 
mips-sgi-irix5 mips-sgi-irix6 mips-kfreebsd-gnu mips-linux mips-img-linux 
mips-mti-linux mips-netbsd mips-rtems mips-vxworks mips-windiss 
mips64-freebsd mips64-kfreebsd-gnu mips64-linux mips64-img-linux 
mips64-mti-linux mips64-openbsd mips64el-ps2-elf mips64el-freebsd 
mips64el-kfreebsd-gnu mips64el-linux mips64el-img-linux mips64el-mti-linux 
mips64el-openbsd mips64vr-elf mips64vr4300-elf mips64vr4300el-elf 
mips64vrel-elf mipsel-elf mipsel-img-elf mipsel-mti-elf mipsel-ps2-elf 
mipsel-sde-elf mipsel-freebsd mipsel-kfreebsd-gnu mipsel-linux 
mipsel-img-linux mipsel-mti-linux mipsel-netbsd mipsel-vxworks 
mipsisa32-elf mipsisa32-linux mipsisa32el-elf mipsisa32el-linux 
mipsisa32r2-elf mipsisa32r2-linux mipsisa32r2el-elf mipsisa32r2el-linux 
mipsisa32r3-elf mipsisa32r3-linux mipsisa32r3el-elf mipsisa32r3el-linux 
mipsisa32r5-elf mipsisa32r5-linux mipsisa32r5el-elf mipsisa32r5el-linux 
mipsisa32r6-elf mipsisa32r6-linux mipsisa32r6el-elf mipsisa32r6el-linux 
mipsisa64-elf mipsisa64-linux mipsisa64el-elf mipsisa64el-linux 
mipsisa64r2-elf mipsisa64r2-linux mipsisa64r2el-elf mipsisa64r2el-linux 
mipsisa64r3-elf mipsisa64r3-linux mipsisa64r3el-elf mipsisa64r3el-linux 
mipsisa64r5-elf mipsisa64r5-linux mipsisa64r5el-elf mipsisa64r5el-linux 
mipsisa64r6-elf mipsisa64r6-linux mipsisa64r6el-elf mipsisa64r6el-linux 
mipsr5900el-elf mipsr5900el-linux tx39-elf

It takes ~20 minutes to verify them all, so not a big deal.

 I'm mostly not set up for verifying compiled tests and I think it would
be infeasible to maintain such a huge number of cross-toolchains (some of 
which I have no access to suitable runtime to).  I remember quirks related 
to PLT vs SVR4 configurations affecting some of those tests.  Overall it 
would be good to get that part cleaned up, but it seems like many engineer 
hours' worth of effort.

 We had discussions on compiled tests before and my conclusion is they're 
really a compromise for the lack of resources to have them implemented as 
individual assembled tests across all the relevant targets.

> Meanwhile, I'm going to correct the ld-elf/eh5 test for hppa64.

 Thank you.  This is indeed the file that conflicted.

 For the record here's my list of non-MIPS targets I use for verification:

aarch64-elf aarch64-linux alpha-dec-vms alpha-linux alpha-linuxecoff 
alpha-netbsd alpha-unknown-freebsd4.7 alpha-unknown-osf4.0 am33_2.0-linux 
arc-elf arc-linux arm-eabi arm-linuxeabi arm-netbsdelf arm-nto arm-pe 
arm-vxworks arm-wince-pe avr-elf bfin-elf bfin-uclinux bpf cr16-elf 
cris-elf crisv32-linux crx-elf csky-elf csky-linux d10v-elf d30v-elf 
dlx-elf fr30-elf frv-elf frv-linux ft32-elf h8300-elf hppa-linux 
hppa-hp-hpux10 hppa64-hp-hpux11.23 hppa64-linux i386-bsd i386-darwin 
i386-linux i386-lynxos i386-msdos i586-linux i686-pc-beos i686-pc-elf 
i686-pe ia64-elf ia64-freebsd5 ia64-hpux ia64-linux ia64-netbsd ia64-vms 
ip2k-elf iq2000-elf lm32-elf m32c-elf m32r-elf m68hc11-elf m68hc12-elf 
m68k-elf m68k-linux m68k-netbsdelf mcore-elf mcore-pe mep-elf metag-elf 
metag-linux microblaze-elf mmix mn10200-elf mn10300-elf mn10300-linux 
moxie-elf ms1-elf msp430-elf nds32be-linux nds32le-linux nios2-linux 
or1k-elf pdp11-dec-aout pj-elf powerpc-beos powerpc-eabisim 
powerpc-ibm-aix5.2.0 powerpc-linux powerpc-nto powerpc-wrs-vxworks 
powerpc64-linux powerpc64le-linux pru-elf riscv32-elf riscv32-linux 
riscv64-elf riscv64-linux rs6000-aix4.3.3 rs6000-aix5.1 rx-elf rx-linux 
s12z-elf s390-linux s390x-linux score-elf sh-elf sh-linux sh-nto sh-pe 
sh-rtems shl-unknown-netbsdelf sparc-linux sparc64-linux spu-elf 
tic30-unknown-coff tic4x-coff tic54x-coff tic6x-elf tic6x-uclinux 
tilegx-linux tilepro-elf v850-elf vax-linux vax-netbsdelf visium-elf 
wasm32 x86_64-elf x86_64-linux x86_64-mingw32 x86_64-solaris2 
xstormy16-elf xtensa-elf z80-coff z80-elf z8k-coff

I tend to update the list with new additions as I remember it every so 
often (I haven't on this occasion) and of course remove obsoleted targets 
as they fail to configure.  Right now ia64-* targets do not build due to a 
GCC warning in GAS.  Then numerous targets have no support in gprofng, so 
I have disabled this tool in configuration.

  Maciej

Re: New failures for the mips64el-openbsd target

[YunQiang Su]

Maciej W. Rozycki <macro@orcam.me.uk> 于2023年6月16日周五 21:33写道：
>
> On Fri, 16 Jun 2023, YunQiang Su wrote:
>
> > >  It may well be that one of the YunQiang Su's patches I have reverted
> > > brough these back; a regression from his earlier commit(s) anyway.
> > >
> >
> > I run a test with the below commit, because the next commit of it is
> > my first commit to binutils.
> >
> > commit 2e6be59c8de57c32260771ac5307968d18793a0a (HEAD -> xxxxx)
> > Author: Nick Clifton <nickc@redhat.com>
> > Date:   Thu Jul 25 13:05:27 2019 +0100
> >
> >     Stop an illegal memory access by readelf when parsing a corrupt
> > MIPS binary file.
> >
> >             PR 24837
> >             * readelf.c (process_mips_specific): Check for buffer overflow
> >             before reading reginfo information.
> >
> > The test fails do exist with this commit.
> >
> > So I think that it is a long time problem, and in fact my recent
> > commits resolve them.
>
>  Good.  Please post fixes then to regressions introduced with any changes
> of yours starting from commit 32f1c80375eb ("MIPS: support mips*64 as CPU
> and gnuabi64 as ABI") as a separate change (or multiple changes) from any
> fixes to pre-existing problems.  The more self-contained a change is the
> more straightforward to review it is.
>

I don't think that 2 changes introduced any "regressions".
Yes, with these 2 changes, if binutils is configured with -
    -target=mips64-linux-gnuabi64 or   -target=mipsisa64r6-linux-gnu
will have some failures. But they are not "regressions", the real problem
is that the previous code is wrong at all.

Yes, I will fix these failures, that the patches do:
    [PATCH v4 3/7] MIPS: Fix r6 testsuites
    [PATCH v4 4/7] MIPS: Fix -gnuabi64 testsuite

>  It's OK to fix regressions one by one with separate patches, or to only
> have an identical change bulk-applied across multiple files in a single
> patch.
>
>  Overall changes that live in downstream repositories often have a long
> history behind them, which is not necessarily relevant at the upstream
> submission time.  Consequently they may have to be merged, split, and/or
> have bits and pieces moved between changes to make them consistent from
> the upstream code's point of view.  I've been through it myself across
> many projects and I am sure I'm no exception here.
>
>  So please try and avoid submitting unrelated changes bundled together in
> a single patch, and of course regression-test each individual change in a
> patch set as they are incrementally applied.
>
>  Also please try and separate changes to the MIPS subset of the testsuites
> from ones to their generic part, as those usually need to be reviewed by a
> general maintainer (unless say you're just about to remove a MIPS XFAIL),
> and also need to be verified across non-MIPS targets.
>
> > >  I haven't run any verification on the reverts as I don't think there is
> > > any excuse for violating our policies and committing patches with no prior
> > > approval and/or with objections raised.  I think let's wait and see how
> > > YunQiang handles it, and if it turns out to be a failure, then I'll handle
> > > it one way or another (maybe his earlier commits need to be reverted too).
> > >
> >
> > I will resend my patchset, of course with more code style checks.
>
>  I look forward to that, thank you.
>
>   Maciej



-- 
YunQiang Su

Re: New failures for the mips64el-openbsd target

[YunQiang Su]

Maciej W. Rozycki <macro@orcam.me.uk> 于2023年6月16日周五 21:33写道：
>
> On Fri, 16 Jun 2023, YunQiang Su wrote:
>
> > >  It may well be that one of the YunQiang Su's patches I have reverted
> > > brough these back; a regression from his earlier commit(s) anyway.
> > >
> >
> > I run a test with the below commit, because the next commit of it is
> > my first commit to binutils.
> >
> > commit 2e6be59c8de57c32260771ac5307968d18793a0a (HEAD -> xxxxx)
> > Author: Nick Clifton <nickc@redhat.com>
> > Date:   Thu Jul 25 13:05:27 2019 +0100
> >
> >     Stop an illegal memory access by readelf when parsing a corrupt
> > MIPS binary file.
> >
> >             PR 24837
> >             * readelf.c (process_mips_specific): Check for buffer overflow
> >             before reading reginfo information.
> >
> > The test fails do exist with this commit.
> >
> > So I think that it is a long time problem, and in fact my recent
> > commits resolve them.
>
>  Good.  Please post fixes then to regressions introduced with any changes
> of yours starting from commit 32f1c80375eb ("MIPS: support mips*64 as CPU
> and gnuabi64 as ABI") as a separate change (or multiple changes) from any
> fixes to pre-existing problems.  The more self-contained a change is the
> more straightforward to review it is.
>
>  It's OK to fix regressions one by one with separate patches, or to only
> have an identical change bulk-applied across multiple files in a single
> patch.
>

I think that before fix these 2 type of failures, we should determine
whether
   [PATCH v4 1/7] MIPS: Gas: alter 64 or 32 for mipsisa triples if
march is implicit
   [PATCH v4 2/7] MIPS: Set r6 as default arch if vendor is img
are OK.

Since these 2 changes will modify the behaviour of GAS, which will make the fix
of testsuite different.
I don't think that making testsuite change and change is a good idea.

>  Overall changes that live in downstream repositories often have a long
> history behind them, which is not necessarily relevant at the upstream
> submission time.  Consequently they may have to be merged, split, and/or
> have bits and pieces moved between changes to make them consistent from
> the upstream code's point of view.  I've been through it myself across
> many projects and I am sure I'm no exception here.
>
>  So please try and avoid submitting unrelated changes bundled together in
> a single patch, and of course regression-test each individual change in a
> patch set as they are incrementally applied.
>
>  Also please try and separate changes to the MIPS subset of the testsuites
> from ones to their generic part, as those usually need to be reviewed by a
> general maintainer (unless say you're just about to remove a MIPS XFAIL),
> and also need to be verified across non-MIPS targets.
>
> > >  I haven't run any verification on the reverts as I don't think there is
> > > any excuse for violating our policies and committing patches with no prior
> > > approval and/or with objections raised.  I think let's wait and see how
> > > YunQiang handles it, and if it turns out to be a failure, then I'll handle
> > > it one way or another (maybe his earlier commits need to be reverted too).
> > >
> >
> > I will resend my patchset, of course with more code style checks.
>
>  I look forward to that, thank you.
>
>   Maciej



-- 
YunQiang Su