From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 464893858424 for ; Sun, 6 Feb 2022 23:39:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 464893858424 Received: by mail-pg1-x532.google.com with SMTP id 75so1695780pgb.4 for ; Sun, 06 Feb 2022 15:39:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sV/pCdKi4l5HpwwcwFsUFHi2Iq5gthu8ZOCywQj+r/A=; b=rnPszgmVCYOxsAEE8fE1KbsBWSQcM9D6WgvQ7mpHHgOtYDVhCQcec9xnIjsf+zkpT0 07RG4+ox7xdfcP86iCYlEVHroWXLe2qdWC5+wJ63FexPi6ikC0/9HXauCsHbVk8wJpXo SId6f9JBAmJ/Tnh3WMEQqRzy8Q/t9lZCE+d1zC1nOV+QIacOOH5fG1TLVM8iWY/O6qrf hgC2DQZWk05CVvyek9EEXa35dHi3NmydDpBQeAf/TMmuvRJv7FUZ8jpAAtA3qyimIiXl +su3FKnaz/mR+8FNkXEbs8oSEkkrUCxnEy7BfUfHXOdVAlynefc994Z+UVZg28j6IhLL lVwQ== X-Gm-Message-State: AOAM531g+4jiQq+RP9bPAmxMk8eOnMk8oHFncYnAWEZ38IJolAtwOTqf tJJpctgPksmq+99V8ZBZ14iM/gHSZicJzATb5b0u3VwX X-Google-Smtp-Source: ABdhPJwL8MtATpdsppE9jrSScAAos8CWj8f3M5nsm0Xt4RrSiO8d9cl/bWnC3sd/0rSaiyjV8zkWmp57jATMFBuVlig= X-Received: by 2002:a63:3e8b:: with SMTP id l133mr7244390pga.210.1644190757282; Sun, 06 Feb 2022 15:39:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Sun, 6 Feb 2022 15:38:41 -0800 Message-ID: Subject: Re: PR28827 testcase To: Alan Modra Cc: Nick Clifton , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3021.8 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: Sun, 06 Feb 2022 23:39:19 -0000 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? > 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. > -- H.J.