* New failures for the mips64el-openbsd target @ 2023-06-15 10:46 Nick Clifton 2023-06-15 14:43 ` Maciej W. Rozycki 0 siblings, 1 reply; 8+ messages in thread From: Nick Clifton @ 2023-06-15 10:46 UTC (permalink / raw) To: macro; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New failures for the mips64el-openbsd target 2023-06-15 10:46 New failures for the mips64el-openbsd target Nick Clifton @ 2023-06-15 14:43 ` Maciej W. Rozycki 2023-06-16 3:00 ` YunQiang Su 2023-06-16 4:29 ` Alan Modra 0 siblings, 2 replies; 8+ messages in thread From: Maciej W. Rozycki @ 2023-06-15 14:43 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New failures for the mips64el-openbsd target 2023-06-15 14:43 ` Maciej W. Rozycki @ 2023-06-16 3:00 ` YunQiang Su 2023-06-16 13:33 ` Maciej W. Rozycki 2023-06-16 4:29 ` Alan Modra 1 sibling, 1 reply; 8+ messages in thread From: YunQiang Su @ 2023-06-16 3:00 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Nick Clifton, binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New failures for the mips64el-openbsd target 2023-06-16 3:00 ` YunQiang Su @ 2023-06-16 13:33 ` Maciej W. Rozycki 2023-06-19 7:12 ` YunQiang Su 2023-06-19 7:23 ` YunQiang Su 0 siblings, 2 replies; 8+ messages in thread From: Maciej W. Rozycki @ 2023-06-16 13:33 UTC (permalink / raw) To: YunQiang Su; +Cc: Nick Clifton, binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New failures for the mips64el-openbsd target 2023-06-16 13:33 ` Maciej W. Rozycki @ 2023-06-19 7:12 ` YunQiang Su 2023-06-19 7:23 ` YunQiang Su 1 sibling, 0 replies; 8+ messages in thread From: YunQiang Su @ 2023-06-19 7:12 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Nick Clifton, binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New failures for the mips64el-openbsd target 2023-06-16 13:33 ` Maciej W. Rozycki 2023-06-19 7:12 ` YunQiang Su @ 2023-06-19 7:23 ` YunQiang Su 1 sibling, 0 replies; 8+ messages in thread From: YunQiang Su @ 2023-06-19 7:23 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Nick Clifton, binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New failures for the mips64el-openbsd target 2023-06-15 14:43 ` Maciej W. Rozycki 2023-06-16 3:00 ` YunQiang Su @ 2023-06-16 4:29 ` Alan Modra 2023-06-16 14:07 ` Maciej W. Rozycki 1 sibling, 1 reply; 8+ messages in thread From: Alan Modra @ 2023-06-16 4:29 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Nick Clifton, binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New failures for the mips64el-openbsd target 2023-06-16 4:29 ` Alan Modra @ 2023-06-16 14:07 ` Maciej W. Rozycki 0 siblings, 0 replies; 8+ messages in thread From: Maciej W. Rozycki @ 2023-06-16 14:07 UTC (permalink / raw) To: Alan Modra; +Cc: Nick Clifton, binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-06-19 7:23 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-06-15 10:46 New failures for the mips64el-openbsd target Nick Clifton 2023-06-15 14:43 ` Maciej W. Rozycki 2023-06-16 3:00 ` YunQiang Su 2023-06-16 13:33 ` Maciej W. Rozycki 2023-06-19 7:12 ` YunQiang Su 2023-06-19 7:23 ` YunQiang Su 2023-06-16 4:29 ` Alan Modra 2023-06-16 14:07 ` Maciej W. Rozycki
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).