https://sourceware.org/bugzilla/show_bug.cgi?id=31924
Tj <tj.iam.tj at proton dot me> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tj.iam.tj at proton dot me
--- Comment #8 from Tj <tj.iam.tj at proton dot me> ---
I've been working on diagnosis in Debian for the last few days and have
collected useful information from building mainline kernels with different
binutils versions. I've shared all the info on my workstation at:
http://[2a0d:3344:11e:1ff0::ff]/binutils-aarch64/
See the included "index.txt" for info; which is copied here:
Debian bug 1074111: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074111
binutils bug 31924: https://sourceware.org/bugzilla/show_bug.cgi?id=31924
This directory contains the product of three mainline kernel builds using the
Debian
aarch64 config taken from 6.9.2-1~exp and found here as ./config-aarch64 and,
for each kernel, the actual build-time generated config.
builds have these suffixes:
Good: -1 built using binutils v2.40 (from Debian Bookworm)
Bad: -3 built using binutils v2.42 20240625
Good: -4 built using binutils v2.42 20240625 with 3 aarch64 DT_RELR patches
reverted
List of reverted commits in ./binutils-gdb.git-revert.commits.log.txt
Kernel image for each is extracted from the Debian package and then ungzipped,
resulting in files with names ./vmlinuz* (compressed) and ./vmlinux*
(uncompressed).
Most visible difference for the Bad kernel is the size:
$ ls -lh vmlinux*
-rw-r--r-- 1 tj tj 37M 2024-06-26 17:48 vmlinux-6.10.0-rc5-1.binutils_2.40_good
-rw-r--r-- 1 tj tj 32M 2024-06-26 17:48
vmlinux-6.10.0-rc5-3.binutils_2.42.20240625_bad
-rw-r--r-- 1 tj tj 37M 2024-06-26 17:44
vmlinux-6.10.0-rc5-4.binutils_2.42.20240625_good_revert_DT_RELR
However, all these files are wrapped in the EFI libstub and there is no
extractor to get to the included vmlinux.
For that reason the kernel build product directories containing all build
product and 'hidden'
".*.cmd" files (and the original ./vmlinux in their base) are included as:
./linux-aarch64.GOOD/
./linux-aarch64.BAD/
What is interesting here is the sizes of the pre- and post- libstub images:
ls -l linux-aarch64.*/vmlinux linux-aarch64.*/arch/arm64/boot/Image
-rw-r--r-- 1 vu-linux-builder-0 vg-linux-builder-0 32619008 2024-06-26 19:50
linux-aarch64.BAD/arch/arm64/boot/Image
-rwxr-xr-x 1 vu-linux-builder-0 vg-linux-builder-0 367529680 2024-06-26 19:50
linux-aarch64.BAD/vmlinux
-rw-r--r-- 1 vu-linux-builder-0 vg-linux-builder-0 38189568 2024-06-27 12:27
linux-aarch64.GOOD/arch/arm64/boot/Image
-rwxr-xr-x 1 vu-linux-builder-0 vg-linux-builder-0 373099856 2024-06-27 12:27
linux-aarch64.GOOD/vmlinux
So I focused on libstub and found in the linker script
drivers/firmware/efi/libstub/zboot.lds
a DISCARD section that I commented out and rebuilt just "Image"
/*
/DISCARD/ : {
*(.discard .discard.*)
*(.modinfo .init.modinfo)
}
*/
This results in "Image" being the same size in the BAD build as in the GOOD:
$ ls -l linux-aarch64.*/arch/arm64/boot/
linux-aarch64.BAD/arch/arm64/boot/:
total 90460
drwxr-xr-x 36 vu-linux-builder-0 vg-linux-builder-0 4096 2024-06-26 19:27
dts
-rw-r--r-- 1 vu-linux-builder-0 vg-linux-builder-0 38189568 2024-06-27 13:14
Image
-rw-r--r-- 1 vu-linux-builder-0 vg-linux-builder-0 12471370 2024-06-27 13:25
Image.gz
-rw-r--r-- 1 vu-linux-builder-0 vg-linux-builder-0 32619008 2024-06-26 19:50
orig.Image
-rw-r--r-- 1 vu-linux-builder-0 vg-linux-builder-0 11500440 2024-06-26 19:50
orig.Image.gz
linux-aarch64.GOOD/arch/arm64/boot/:
total 49304
drwxr-xr-x 36 vu-linux-builder-0 vg-linux-builder-0 4096 2024-06-27 12:04
dts
-rw-r--r-- 1 vu-linux-builder-0 vg-linux-builder-0 38189568 2024-06-27 12:27
Image
-rw-r--r-- 1 vu-linux-builder-0 vg-linux-builder-0 12467722 2024-06-27 12:27
Image.gz
Installing the resulting Image.gz in the OS test image results in a correct
boot.
Investigating the 'BAD' build logs (./build-*-3*.log) I see that even with the
kernel's setting
ld's --pack-relative-relocs that without the DISCARD section the kernel
executes correctly.
--
You are receiving this mail because:
You are on the CC list for the bug.
