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.
