On 8/19/20 7:27 PM, Fāng-ruì Sòng wrote:
section(36) .comment, size 44, link 0, flags 30, type=1 section(37) .debug_aranges, size 45684, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 16, expected 8 section(38) .debug_info, size 129104957, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(39) .debug_abbrev, size 1152583, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(40) .debug_line, size 7374522, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(41) .debug_frame, size 702463, link 0, flags 800, type=1 section(42) .debug_str, size 1017571, link 0, flags 830, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(43) .debug_loc, size 3019453, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(44) .debug_ranges, size 1744583, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 16, expected 8 section(45) .symtab, size 2955888, link 46, flags 0, type=2 section(46) .strtab, size 2613072, link 0, flags 0, type=3I think this is resolve_btfids's bug. GNU ld and LLD are innocent. These .debug_* sections work fine if their sh_addralign is 1. When the section flag SHF_COMPRESSED is set, the meaningful alignment is Elf64_Chdr::ch_addralign, after the header is uncompressed. On Wed, Aug 19, 2020 at 2:30 PM Yonghong Song <yhs@xxxxxx> wrote:On 8/19/20 11:16 AM, Nick Desaulniers wrote:On Wed, Aug 19, 2020 at 10:36 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:On Wed, Aug 19, 2020 at 08:31:51AM -0700, Yonghong Song wrote:On 8/19/20 2:23 AM, Jiri Olsa wrote:The data of compressed section should be aligned to 4 (for 32bit) or 8 (for 64 bit) bytes. The binutils ld sets sh_addralign to 1, which makes libelf fail with misaligned section error during the update as reported by Jesper: FAILED elf_update(WRITE): invalid section alignment
Jiri, Since Fangrui mentioned this is not a ld/lld bug, then changing alighment from 1 to 4 might have some adverse effect for the binary, I guess.Do you think we could skip these .debug_* sections somehow in elf parsing in resolve_btfids? resolve_btfids does not need to read
these sections. This way, no need to change their alignment either. Yonghong
While waiting for ld fix, we can fix compressed sections sh_addralign value manually.Is there a bug filed against GNU ld? Link?Adding warning in -vv mode when the fix is triggered: $ ./tools/bpf/resolve_btfids/resolve_btfids -vv vmlinux ... section(36) .comment, size 44, link 0, flags 30, type=1 section(37) .debug_aranges, size 45684, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 16, expected 8 section(38) .debug_info, size 129104957, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(39) .debug_abbrev, size 1152583, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(40) .debug_line, size 7374522, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(41) .debug_frame, size 702463, link 0, flags 800, type=1 section(42) .debug_str, size 1017571, link 0, flags 830, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(43) .debug_loc, size 3019453, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 1, expected 8 section(44) .debug_ranges, size 1744583, link 0, flags 800, type=1 - fixing wrong alignment sh_addralign 16, expected 8 section(45) .symtab, size 2955888, link 46, flags 0, type=2 section(46) .strtab, size 2613072, link 0, flags 0, type=3 ... update ok for vmlinux Another workaround is to disable compressed debug info data CONFIG_DEBUG_INFO_COMPRESSED kernel option.So CONFIG_DEBUG_INFO_COMPRESSED is required to reproduce the bug, right?correctI turned on CONFIG_DEBUG_INFO_COMPRESSED in my config and got a bunch of build failures. ld: drivers/crypto/virtio/virtio_crypto_algs.o: unable to initialize decompress status for section .debug_info ld: drivers/crypto/virtio/virtio_crypto_algs.o: unable to initialize decompress status for section .debug_info ld: drivers/crypto/virtio/virtio_crypto_algs.o: unable to initialize decompress status for section .debug_info ld: drivers/crypto/virtio/virtio_crypto_algs.o: unable to initialize decompress status for section .debug_info drivers/crypto/virtio/virtio_crypto_algs.o: file not recognized: File format not recognized ld: net/llc/llc_core.o: unable to initialize decompress status for section .debug_info ld: net/llc/llc_core.o: unable to initialize decompress status for section .debug_info ld: net/llc/llc_core.o: unable to initialize decompress status for section .debug_info ld: net/llc/llc_core.o: unable to initialize decompress status for section .debug_info net/llc/llc_core.o: file not recognized: File format not recognized ... The 'ld' in my system: $ ld -V GNU ld version 2.30-74.el8 Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu i386linux elf_l1om elf_k1om i386pep i386peAccording to Documentation/process/changes.rst, the minimum supported version of GNU binutils for the kernels is 2.23. Can you upgrade to that and confirm that you still observe the issue? I don't want to spend time chasing bugs in old, unsupported versions of GNU binutils, especially as Jiri notes, 2.26 is required for CONFIG_DEBUG_INFO_COMPRESSED. We can always strengthen the Kconfig check for it. Otherwise, I'm not familiar with the observed error message.I built a "ld" with latest binutils-gdb repo and I can reproduced the issue. Indeed applying the patch here fixed the issue. So I think there is no need to investigate since upstream exhibits the exact issue described here.$ Do you know what is the issue here?mine's: GNU ld version 2.32-31.fc31 there's version info in commit: 10e68b02c861 Makefile: support compressed debug info Compress the debug information using zlib. Requires GCC 5.0+ or Clang 5.0+, binutils 2.26+, and zlib. cc-ing Nick Desaulniers, author of that patch.. any idea about the error above? thanks, jirka
