bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/30033] binutils-2.40 broke arm-linux-gnueabi libraries on


From: arnd at arndb dot de
Subject: [Bug binutils/30033] binutils-2.40 broke arm-linux-gnueabi libraries on arm64 kernel with >4KB pages
Date: Mon, 23 Jan 2023 21:36:47 +0000

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

Arnd Bergmann <arnd at arndb dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|arm-linux-gnuabihf          |arm-linux-gnueabihf

--- Comment #3 from Arnd Bergmann <arnd at arndb dot de> ---
The case I ran into was trying to create a bootable disk image for a Debian
armhf or armel system using the 'mmdebstrap' tool. The system does support
running 'compat' userspace on the CPU itself, so this uses the 'qemu-user-arm'
tool to run the installation process, but the problem is the same as when
running compat userspace.

mmdebstrap is useful for me to quickly test a 32-bit kernel image with a
working userspace, and it works fine on the other architectures supported by
Debian, as well as on stable Debian arm releases that were produced with
binutils versions 2.25 (which added support for 64KB page alignment) through
2.39.

My workstation is an Apple M1 based system that only works with 16KB pages, the
only other alternative I have would be to test on a much slower Chromebook, or
an cloud instance.

Regarding the kernel option, support for running 32-bit binaries with larger
pages was added experimentally at the same time as binutils support, but at the
time no distributions were built with new enough binutils yet so it was left
under CONFIG_EXPERT, see
https://lore.kernel.org/linux-arm-kernel/20141204182049.GB7749@arm.com/. Since
all distributions that are still supported now are built with binutils-2.25 or
higher, this is probably something that could be revisited, especially as more
users are going to want 16KB page support in their kernels, which has a better
tradeoff between performance and space overhead than using 64KB pages.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]