[Bug binutils/30033] binutils-2.40 broke arm-linux-gnueabi libraries on arm64 kernel with >4KB pages

[hp at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30033

--- Comment #2 from Hans-Peter Nilsson <hp at sourceware dot org> ---
An "armhf" userspace on a "arm64" kernel with non-4KiB pagesize is an odd
beast, odd enough that it's hidden behind EXPERT settings when building the
kernel and warnings about having to rebuild tools.

Quoting linux/arch/arm64/Kconfig as of c8451c141e07:

menuconfig COMPAT
        bool "Kernel support for 32-bit EL0"
        depends on ARM64_4K_PAGES || EXPERT
        select HAVE_UID16
        select OLD_SIGSUSPEND3
        select COMPAT_OLD_SIGACTION
        help
          This option enables support for a 32-bit EL0 running under a 64-bit
          kernel at EL1. AArch32-specific components such as system calls,
          the user helper functions, VFP support and the ptrace interface are
          handled appropriately by the kernel.

          If you use a page size other than 4KB (i.e, 16KB or 64KB), please be
aware
          that you will only be able to execute AArch32 binaries that were
compiled
          with page size aligned segments.

          If you want to execute 32-bit userspace applications, say Y.


Is this non-4KiB page-size + armhf userspace part of an easily accessible
distribution?  Please tell more.

It's a judgement call; you can't have it all with the default build.  I
mentioned that this setup would break, but my argument was and is also, that
such a setup is odd enough, that people with it have to build tools specially,
or use special options like ld -z max-page-size=0x10000, rather than bloating
for everyone else.  See the mailing list discussion at the time.

Are there reasons to reconsider this setup any more common than as portrayed;
an odd corner-case where users are developers ready to patch and build tools
themselves?

-- 
You are receiving this mail because:
You are on the CC list for the bug.