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