Re: New failures for the mips64el-openbsd target

["Maciej W. Rozycki" <macro@orcam.me.uk>]

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