From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 9FC813858D35 for ; Fri, 16 Jun 2023 13:33:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9FC813858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 21F7992009C; Fri, 16 Jun 2023 15:33:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 1B69C92009B; Fri, 16 Jun 2023 14:33:44 +0100 (BST) Date: Fri, 16 Jun 2023 14:33:44 +0100 (BST) From: "Maciej W. Rozycki" To: YunQiang Su cc: Nick Clifton , binutils@sourceware.org Subject: Re: New failures for the mips64el-openbsd target In-Reply-To: Message-ID: References: <87zg51m295.fsf@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1163.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 > 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