From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 4BCCA3858426 for ; Mon, 7 Feb 2022 03:15:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4BCCA3858426 Received: by mail-pf1-x42c.google.com with SMTP id n32so10635287pfv.11 for ; Sun, 06 Feb 2022 19:15:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ygnIUrWeZutCSAMw7JfolxBfCRtj3yi7n95UFe1bohU=; b=Aq4mbot8vpdPHFOIWqF9zg2NcSfvzj4JV+3qff/46a6ktmUpIrJmaIj4s/t8ZD/MfI sCY06WRwLmyfcTFP5VmFbgxHC8A8f8NUkyy7+ncTzNs4IB9vwRpUJGIbLNFr5MoOEESH BPAPoHWBAtfBzlUh5QwUSgv3Nnn/WdLsX1isCTwkHnn2m9SojNdgLQIRCk8OQaHwUv1G +zMM39Go3bRXsSlGfdqqu535wjBdg4FNY1SwIw8JM0b/tJZJXoXX53Vby0H1IVZY2X1o fVfmquj3cBq8pcbnAHWssrJS5zEobTLO46yGLdKnYiHEJ2N8CQHBkDtoWhwjyfu4k9az ATAw== X-Gm-Message-State: AOAM532kXg/wJ73FR/wvo/KGwIakjb/g55haTPs9v73SSbXtirDKz93M Kd43XhObS3ERLiJsTS1g3yc= X-Google-Smtp-Source: ABdhPJyT3n0Ol3ZYxxQMgmZpvNVnv4gsBQRhmYxbqsJlirqHOLTQLQsNf6eBx0TZqsRGuOQGREYIVw== X-Received: by 2002:aa7:8c4a:: with SMTP id e10mr13849516pfd.43.1644203756344; Sun, 06 Feb 2022 19:15:56 -0800 (PST) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id 17sm10294240pfl.175.2022.02.06.19.15.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Feb 2022 19:15:55 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 398FB11403AA; Mon, 7 Feb 2022 13:45:53 +1030 (ACDT) Date: Mon, 7 Feb 2022 13:45:53 +1030 From: Alan Modra To: "H.J. Lu" Cc: Nick Clifton , Binutils Subject: Re: PR28827 testcase Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3032.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 03:15:59 -0000 On Sun, Feb 06, 2022 at 03:38:41PM -0800, H.J. Lu wrote: > On Sun, Feb 6, 2022 at 2:54 PM Alan Modra wrote: > > > > On Sat, Feb 05, 2022 at 08:26:55PM -0800, H.J. Lu wrote: > > > On Sun, Feb 06, 2022 at 02:47:19PM +1030, Alan Modra via Binutils wrote: > > > > On Sat, Feb 05, 2022 at 10:39:50AM +0000, Nick Clifton wrote: > > > > > Hi Alan, Hi Fangrui, > > > > > > > > > > > This testcase triggers a stub sizing error with the patches applied > > > > > > for PR28743 (commit 2f83249c13d8 and c804c6f98d34). > > > > > > > > > > > > PR 28827 > > > > > > * testsuite/ld-powerpc/pr28827-1.s, > > > > > > * testsuite/ld-powerpc/pr28827-1.d: New test. > > > > > > * testsuite/ld-powerpc/powerpc.exp: Run it. > > > > > > > > > > Given the importance of the PowerPC target, I am going to hold > > > > > off from creating the 2.38 release until this issue is fixed. > > > > > > > > Thanks, I appreciate it. > > > > > > > > > I do hope however that it can be resolved soon.... > > > > > > > > The solution is to revert HJ's two relro patches on the branch. That > > > > will let you immediately make a release. Despite being raised by > > > > Florian, I don't believe PR28743 is an important bug to fix just > > > > before a release. Our relro support has sometimes created a hole for > > > > *years*. > > > > > > > > Of course, the patches ought to be reverted on mainline too, > > > > separately from whatever solution we finally adopt for PR28743. > > > > > > > > > > Why make removing the 1-page gap before the PT_GNU_RELRO segment opt-in? > > > > > > https://sourceware.org/pipermail/binutils/2022-February/119625.html > > > > I happen to think your changes to lang_size_relro_segment_1 are wrong. > > Making them optional doesn't fix that. > > So far, it has been working for x86. Do you have a testcase to show > otherwise? Just put an ASSERT(0) on the do_reset code path. > > The major reason is that I question the premise behind the patch. Is > > it really worth wasting up to maxpagesize-1 in memory at the end of > > My patches shouldn't create a gap of more than 1-page at the end. > If it isn't the case, do you have a testcase for x86? I don't see the > value of a 1-page gap before RELRO segment on x86. I'd like to > avoid it on x86 if possible. > > > the relro segment in order to remove a page gap at the beginning of > > the relro segment? That seems a dubious trade-off to me. If process > > memory is an issue then it would be better to increase disk image size > > for reduced memory size. > > > > There is also the fact that we now hit the do_reset code path in > > lang_size_relro_segment when running multiple ld tests. I think that > > says the current implementation is broken. I'm tired of arguing. Your brokem patches have been reverted. -- Alan Modra Australia Development Lab, IBM