ARM: Fix ld bloat introduced between binutils-2.38 and 2.39

[Hans-Peter Nilsson]

> From: Alan Modra <amodra@gmail.com>
> CC: "binutils@sourceware.org" <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