From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 786D33858D37 for ; Mon, 7 Feb 2022 05:32:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 786D33858D37 Received: by mail-pl1-x62f.google.com with SMTP id u12so3194926plq.10 for ; Sun, 06 Feb 2022 21:32:35 -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=cegxJte3m9Vtcyo7Y+HzkHewdtpZJmfzJzuQDBtEgdY=; b=D0E/PWea8IotDSZezdqo+GiFAT866rAPlwQxrHPhcizT+WF0W73y0n9mqgdhq2LnHX sAq346Hx828HTvSktovZVz5yt/eVCVhruENaSKbKgPWWTdfAUrVqUcgXVBA/kC1qa+gj 25bH29HYQ/2ZcxUqf0HceRRV0jFkvp+5XMZqnaXvszpcOmlXFw/k1XdD2WAUpou3JJgi Q+bag7ayRNvt8sUiIj+8g8PQWcB8Qa5oIuG8bL2TG9qUsz6sUXQ7rJddYae/criQlTIz yjxCkq6iB7RRSvTFBdPG07VQOWSk8YeaKJu0YffdpJzEWDfsEkop3k8p3ShsVLfXTZhN RYNw== X-Gm-Message-State: AOAM530AZ4J2xXxuzUSzW4wIpZaEViZxnS/GoNpwnnJQ7reCmt3DyUzN vwg9wVlPDsPCpUjK1wJi0Bo= X-Google-Smtp-Source: ABdhPJwaEPpfO8mdczvQBqn9Af7i9sj+HASsEeT1CaxgL20qdEy9IyI7sPKpAU8fbuyKnqo/rQmo4w== X-Received: by 2002:a17:90b:4b01:: with SMTP id lx1mr16678956pjb.158.1644211954548; Sun, 06 Feb 2022 21:32:34 -0800 (PST) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:7f3:5e41:4caf:2c0c]) by smtp.gmail.com with ESMTPSA id nn12sm20623954pjb.24.2022.02.06.21.32.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Feb 2022 21:32:33 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 322BE11404CF; Mon, 7 Feb 2022 16:02:31 +1030 (ACDT) Date: Mon, 7 Feb 2022 16:02:31 +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=-3037.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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 05:32:39 -0000 On Sun, Feb 06, 2022 at 08:05:38PM -0800, H.J. Lu wrote: > On Linux/x86-64, I tried this with binutils-2_37-branch: > > diff --git a/ld/ldlang.c b/ld/ldlang.c > index 042b492d52b..4760d45721a 100644 > --- a/ld/ldlang.c > +++ b/ld/ldlang.c > @@ -6509,13 +6509,18 @@ lang_size_sections (bool *relax, bool check_regions) > > if (expld.dataseg.phase == exp_seg_end_seen) > { > + static int reset_counter; > + > bool do_reset > = lang_size_relro_segment (relax, check_regions); > > if (do_reset) > { > + reset_counter++; > lang_reset_memory_regions (); > one_lang_size_sections_pass (relax, check_regions); > + if (reset_counter > 2) > + abort (); > } > > if (link_info.relro && expld.dataseg.relro_end) Not there. Here: diff --git a/ld/ldlang.c b/ld/ldlang.c index 37b64c89ee1..d7c6551217e 100644 --- a/ld/ldlang.c +++ b/ld/ldlang.c @@ -6404,7 +6404,8 @@ lang_size_relro_segment (bool *relax, bool check_regions) script have increased padding over the original. Revert. */ if (do_data_relro && expld.dataseg.relro_end > data_relro_end) { - expld.dataseg.base = data_initial_base;; + expld.dataseg.base = data_initial_base; + ASSERT (0); do_reset = true; } } Not hit in 2.37, multiple cases in mainline with your patches applied. I saw iteration in ldelf_map_segments too. > Is there a way to enable my patches just for x86? Yes, but not in their current form. I intend to apply a fix for pr28824 that also cures pr28743, at the expense of a possible file size increase. This will regress pr18176. It must, because pr18176.d has a relro section that ends at 0x24e000 which isn't a multiple of maxpagesize of 0x200000. After that you are free to trade off increased memory on x86 for reduced file size if that is important to you. -- Alan Modra Australia Development Lab, IBM