https://sourceware.org/bugzilla/show_bug.cgi?id=32048
--- Comment #10 from Claudio Luck <c.luck at datact dot ch> --- Please note that due to the abovementioned commit, GNU/Linux is effectively banned from many 32bit arm systems (and some 64bit arm systems with 32bit userland support). Said commit https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1a26a53a0dee39106ba58fcb15496c5f13074652 was made to revert the space increase of binaries introduced by the fix of "relro security issue" https://sourceware.org/bugzilla/show_bug.cgi?id=28824. The commit message shows that there were wrong assumptions at play. Contrary to the commit message, 32bit Kernels with larger pagesizes do exist in commercially available platforms: [~] # uname -a Linux QNAP-NAS 4.2.8 #2 SMP Wed Jan 8 03:49:48 CST 2025 armv7l GNU/Linux [~] # zcat /proc/config.gz | grep PAGE_SIZE CONFIG_ARM_PAGE_SIZE_LARGE=y # CONFIG_ARM_PAGE_SIZE_64KB is not set CONFIG_ARM_PAGE_SIZE_32KB=y # CONFIG_ARM_PAGE_SIZE_4KB is not set CONFIG_ARM_PAGE_SIZE_LARGE_SHIFT=15 Also, it is unclear how the larger binary size is a practical problem in the first place, since compressed root filesystems are ubiquituous (the added padding compresses particularly well). And in the greater context, there seems to be a "more proper" way to eliminate the space increase while also keeping pagesize compatibility: In https://sourceware.org/bugzilla/show_bug.cgi?id=30033#c5 it was mentioned that the mold linker and LLVM had found a better workaround to avoid the space increase (namely to map the boundary page twice) while still supporting all pagesizes. It was concluded that GNU ld could implement the same technique. 1,5 years earlier, though, Fangrui Song in https://sourceware.org/bugzilla/show_bug.cgi?id=30612#c1 stated that "this is nearly infeasible to fix, as long as the alignment still follows max-page-size, as switching to a two-RW-PT_LOAD layout in GNU ld is very difficult." Thus, not expecting an imminent implementation of a "proper" workaround, I politely ask to consider reverting 1a26a53a0dee39106ba58fcb15496c5f13074652. -- You are receiving this mail because: You are on the CC list for the bug.
