From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 575DB3858D3C for ; Sun, 6 Feb 2022 22:54:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 575DB3858D3C Received: by mail-pf1-x432.google.com with SMTP id i30so10075850pfk.8 for ; Sun, 06 Feb 2022 14:54:28 -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=7J0HQoZPweb8T6WaLvZ/HzFLHqTqOy7x725ROtb5VtA=; b=67KlZLVwKZskp8DNWlVTvTD6YdcaVzhRn5CeOByPifyJ6RQcy8YHwU90QkYt/zShDA D5kCXCNusvaP+b12yl9FCKy60MwL7Bg0ja3luTmdOOQNs4iVG5CtzlhZVLD+BcnEu5uZ mBrBd+8IuEaMk2pAK1RoPS0PRyAEMss5gBPBBycJinhc0HYqW6CndqBu2ilJHaAK8tT1 ULo0TJjDj5J90W3+WPS0JYiyx0W1nXnjID4ZiVf5jSxEEAyahr6OVsAcuR/52Q8PxQXn BplHa5X50woccc4Q8rCxAD3fCnQYsTGVgoDABopYbSrf/Ddf4DLKsBNAYstlBklY6nOD MrJQ== X-Gm-Message-State: AOAM533huGmyBfgbNMt33iv9FIoE8RLEC5P6/8Lv17uHad9g9fFWZa88 f8jki8AIVRGdMX4xRlhmbhk= X-Google-Smtp-Source: ABdhPJxOB7bl+/UyDt/QFEMIQ7Q7RKNkU6OHUR8RB9xhwCJHdNQugZSkusZUd4Gbp+8kE9tnI9/Hzg== X-Received: by 2002:a63:2a95:: with SMTP id q143mr7359000pgq.492.1644188067522; Sun, 06 Feb 2022 14:54:27 -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 m21sm9882236pfk.26.2022.02.06.14.54.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Feb 2022 14:54:26 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 9259711404CF; Mon, 7 Feb 2022 09:24:23 +1030 (ACDT) Date: Mon, 7 Feb 2022 09:24:23 +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: Sun, 06 Feb 2022 22:54:30 -0000 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. 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 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. -- Alan Modra Australia Development Lab, IBM