Re: [PATCH] vmlinux.lds.h: Force-align ELF notes section to four bytes

[Tianyi Liu]

On Thu, Apr 13, 2023 at 02:21:49 +0000, Joan Bruguera Micó wrote:
> I have done some tests with Arch Linux which is also affected by this issue:
> 
> Base scenario: Running Arch Linux updated as of 2023-04-13.
>                Building the linux-mainline 6.3rc6-1 from AUR
>                (https://aur.archlinux.org/packages/linux-mainline)
>                with CONFIG_X86_KERNEL_IBT changed to 'y'
> Result:        Build fails with the "btf__dedup failed!" error

I use MANJARO with kernel version 6.2.10-1. We should be using the same kernel.

> Test 1: Update dwarves (=pahole package on Arch Linux) from the current version
>         (1:1.24+r29+g02d67c5-1) to the staging version (1:1.25-1).
> Result: The build works correctly.
> 
>         However, the notes section is still not parsed correctly, as confirmed
>         by `readelf -n` or adding a printf near the code on `cus__merging_cu`
>         (on `dwarf_loader.c`) pointed to by Tianyi.
> 
>         A bisect shows the commit that fixes the build is
>         a9498899109d3be14f17abbc322a8f55a1067bee
>         "dwarf_loader: Fix for BTF id drift caused by adding unspecified types"
>         I don't know why though.

Pahole reads .notes to look for LINUX_ELFNOTE_BUILD_LTO. When LTO is
enabled, pahole needs to call cus__merge_and_process_cu to merge compile
units, at which point there should only be one unspecified type (used to
represent some compilation information) in the global context.

However, when the kernel is compiled without LTO, if pahole calls
cus__merge_and_process_cu due to alignment issues with notes, multiple
unspecified types may appear after merging the cus, and older versions of
pahole only support up to one. This is why pahole 1.24 crashes, while
newer versions support multiple. However, the latest version of pahole
still does not solve the problem of incorrect LTO recognition, so
compiling the kernel may be slower than normal.

If the only objective is to fix the bug of incorrect LTO recognition,
perhaps this naive patch[1] could be sufficient.

[1]: https://lore.kernel.org/bpf/SY4P282MB1084A0E31D4228DF89FC42639DA29@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

> Test 2: Applying Josh's patch to force-align the ELF notes section to 4 bytes
>         (clarification: using the base pahole version again here)
> Result: The build works correctly.
>         I can read the notes correctly using `readelf -n` as well,
>         and they are aligned to 4 bytes instead of 8.

I'm still currently unable to reproduce this fix, but it may just be an
issue with my environment.

> Test 3: Similar to Josh's patch, but instead of force-aligning the sections,
>         I added `.note.gnu.property` to the `/DISCARD/` list in the line above.
> Result: The build works correctly.
>         I can read the notes correctly using `readelf -n` as well
>         (of course, the GNU notes which made the alignment be 8 bytes are gone;
>          I don't know if this has any negative effect).

I think discarding .note.gnu.property will not have side effects. For some
reason, this note does not exist in my final vmlinux. I also did not find
any usage of this property in the later steps of compiling the kernel.

> So, in summary, either upgrading dwarves/pahole from 1.24 to (not yet fully
> released?) 1.25, or applying Josh's patch fixes the issue for me.
> Despite the new dwarves/pahole version fixing the build, Josh's patch or
> something else to fix the notes alignment is needed.