From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by sourceware.org (Postfix) with ESMTPS id 946BE3858D1E for ; Tue, 3 Jan 2023 02:41:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1672713680; x=1704249680; h=from:to:cc:in-reply-to:subject:mime-version: content-transfer-encoding:references:message-id:date; bh=+u82SaYsIaj63Fed+jo9y6YTEw5tUNIC26qGucGFBVw=; b=U5u5s+B3ePy49mlqPYdlOkalYBDZgFKEhzwbPuevwjl4qgfEXOluRY0U FUZeudHzhN8tdequdVkqPprpMmAb9R0Cd52mvNYAOSKLA/NSVCw9XuICm JYe3b0QQ6LbXqqqYerVf7Sb9lLVjUKJWKh/C6j++5e/Jstwi2krpoIYUm FFdrlXP+SVS9YBUvqux5s4sXUjRgNF7JgXWk0o1Skp5GHZmnkKGxuEwoj 3EGqW/+7FF39dBZ0O4e3+M0HSEDbVQXFojQhiX9fTWfR7dP912efx5Xud L7mWnjmvgKFOLr90y5NQVJwSKhl34DGxrY2ga+zv+Loi+ncRtMBhdVNGX g==; From: Hans-Peter Nilsson To: Alan Modra CC: In-Reply-To: (message from Alan Modra on Tue, 3 Jan 2023 02:35:27 +0100) Subject: ARM: Fix ld bloat introduced between binutils-2.38 and 2.39 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT References: <20230102160857.ABA7F2042C@pchp3.se.axis.com> Message-ID: <20230103024119.12F182042C@pchp3.se.axis.com> Date: Tue, 3 Jan 2023 03:41:19 +0100 X-Spam-Status: No, score=-10.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Alan Modra > CC: "binutils@sourceware.org" > On Mon, Jan 02, 2023 at 05:08:57PM +0100, Hans-Peter Nilsson via Binutils wrote: > > That may sound like an argument for setting the bfd_arch_arm > > ELF_MAXPAGESIZE to 4 KiB, but then the obscure corner-case > > wouldn't be properly handled. > > Agreed. It's what x86 did when facing the same thing. If anybody > cares about the obscure corner-case you identify then they can just > use -z max-page-size. Or edit elf32-arm.c. I see where this is going, but... > > Instead, I suggest simply making ELF_MAXPAGESIZE generally > > overridable by means of a --with option at linker > > configuration time. > > I dislike configure time options that affect linker behaviour, but I > realise I'm flogging a dead horse since we already have a lot of them. > However, this particular option is worse than most since it affects > all ELF targets. That can't be correct or useful with > --enable-targets=all. I have to say that people using --enable-targets=all to build their linkers definitely shouldn't be using this option, as their definition of "all" then doesn't include obscure corner cases! And how do the "--enable-targets=all"-people link? IIUC they have to specify an emulation when using such a linker, so they can't be using a general invocation. To wit, I don't think the "--enable-targets=all"-breakage is a valid counter-argument. Anyway, here's the obvious alternative. It needs to have the ARM testsuite adjusted (not included, will fix and send for separate consideration on approval). Ok for master, 2.40 and 2.39? --- 8< --- Subject: ARM: Fix ld bloat introduced between binutils-2.38 and 2.39 Since commit 9833b7757d24, "PR28824, relro security issues", ELF_MAXPAGESIZE matters much more, with regards to layout of the linked file. That commit fixed an actual bug, but also exposes a problem for targets were that value is too high. For example, for ARM(32, a.k.a. "Aarch32") specifically bfd_arch_arm, it's set to 64 KiB, making all Linux(/GNU) targets pay an extra amount of up to 60 KiB of bloat in DSO:s and executables. This matters when there are many such files, and where storage is expensive. It's *mostly* bloat when using a Linux kernel, as ARM(32) is a good example of an target where ELF_MAXPAGESIZE is set to an extreme value for an obscure corner-case. The ARM (32-bit) kernel has 4 KiB pages, has had that value forever, and can't be configured to any other value. The use-case is IIUC "Aarch32" emulation on an "Aarch64" (arm64) kernel, but not just that, but a setup where the Linux page-size is configured to something other than the *default* 4 KiB. Not sure there actually any such systems in use, again with both Aarch32 compatibility support and a non-4KiB pagesize, with all the warnings in the kernel config and requiring the "EXPERT" level set on. So, let's do like x86-64 in a2267dbfc9e1 "x86-64: Use only one default max-page-size" and set ELF_MAXPAGESIZE to 4096. bfd: * elf32-arm.c (ELF_COMMONPAGESIZE): Always set to 0x1000. --- bfd/elf32-arm.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c index 0cd3aec14368..b83c43c741c9 100644 --- a/bfd/elf32-arm.c +++ b/bfd/elf32-arm.c @@ -20261,11 +20261,7 @@ elf32_arm_backend_symbol_processing (bfd *abfd, asymbol *sym) #define ELF_ARCH bfd_arch_arm #define ELF_TARGET_ID ARM_ELF_DATA #define ELF_MACHINE_CODE EM_ARM -#ifdef __QNXTARGET__ #define ELF_MAXPAGESIZE 0x1000 -#else -#define ELF_MAXPAGESIZE 0x10000 -#endif #define ELF_COMMONPAGESIZE 0x1000 #define bfd_elf32_mkobject elf32_arm_mkobject -- 2.30.2