From: YunQiang Su <wzssyqa@gmail.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Nick Clifton <nickc@redhat.com>, binutils@sourceware.org
Subject: Re: New failures for the mips64el-openbsd target
Date: Fri, 16 Jun 2023 11:00:42 +0800 [thread overview]
Message-ID: <CAKcpw6WopsQ3zBuxyDtU1EtiKK9DR5Fzjiav3w5J8G6ERBN5+A@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2306151532540.64925@angie.orcam.me.uk>
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
next prev parent reply other threads:[~2023-06-16 3:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 10:46 Nick Clifton
2023-06-15 14:43 ` Maciej W. Rozycki
2023-06-16 3:00 ` YunQiang Su [this message]
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
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=CAKcpw6WopsQ3zBuxyDtU1EtiKK9DR5Fzjiav3w5J8G6ERBN5+A@mail.gmail.com \
--to=wzssyqa@gmail.com \
--cc=binutils@sourceware.org \
--cc=macro@orcam.me.uk \
--cc=nickc@redhat.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).