* die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled!
@ 2022-09-27 18:56 Nathan Chancellor
2022-09-27 19:08 ` Arnaldo Carvalho de Melo
2022-09-28 21:35 ` Nick Desaulniers
0 siblings, 2 replies; 12+ messages in thread
From: Nathan Chancellor @ 2022-09-27 18:56 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Nick Desaulniers; +Cc: dwarves, llvm
Hi Arnaldo,
When building a kernel with LLVM and CONFIG_DEBUG_INFO_BTF after commit
32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") in
the kernel, I see the following spew of warnings, which appear to come
from pahole:
$ clang --version
clang version 15.0.0 (Fedora 15.0.0-3.fc38)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ pahole --version
v1.24
$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
$ scripts/config \
-d DEBUG_INFO_NONE \
-e BPF_SYSCALL \
-e DEBUG_INFO_BTF \
-e DEBUG_INFO_DWARF5
$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all
...
die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled!
die__process_unit: tag not supported 0xa (label)!
die__process_unit: DW_TAG_label (0xa) @ <0x97> not handled!
die__process_unit: DW_TAG_label (0xa) @ <0xbd> not handled!
die__process_unit: DW_TAG_label (0xa) @ <0xed> not handled!
die__process_unit: DW_TAG_label (0xa) @ <0x109> not handled!
die__process_unit: DW_TAG_label (0xa) @ <0x12a> not handled!
die__process_unit: DW_TAG_label (0xa) @ <0x146> not handled!
die__process_unit: DW_TAG_label (0xa) @ <0x16f> not handled!
...
Is this a problem with LLVM or pahole? I do not see this when building
with GCC + GNU as but that could just be a red herring. I assume that
there could be something missing for processing debug info from
assembly, perhaps? If there is any further information I can provide or
anything I can test, I am more than happy to do so.
Cheers,
Nathan
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-27 18:56 die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! Nathan Chancellor @ 2022-09-27 19:08 ` Arnaldo Carvalho de Melo 2022-09-27 19:59 ` Nathan Chancellor 2022-09-28 21:35 ` Nick Desaulniers 1 sibling, 1 reply; 12+ messages in thread From: Arnaldo Carvalho de Melo @ 2022-09-27 19:08 UTC (permalink / raw) To: Nathan Chancellor; +Cc: Nick Desaulniers, dwarves, llvm Em Tue, Sep 27, 2022 at 11:56:34AM -0700, Nathan Chancellor escreveu: > Hi Arnaldo, > > When building a kernel with LLVM and CONFIG_DEBUG_INFO_BTF after commit > 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") in > the kernel, I see the following spew of warnings, which appear to come > from pahole: > > $ clang --version > clang version 15.0.0 (Fedora 15.0.0-3.fc38) > Target: x86_64-redhat-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > > $ pahole --version > v1.24 > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig > > $ scripts/config \ > -d DEBUG_INFO_NONE \ > -e BPF_SYSCALL \ > -e DEBUG_INFO_BTF \ > -e DEBUG_INFO_DWARF5 > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all > ... > die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! > die__process_unit: tag not supported 0xa (label)! > die__process_unit: DW_TAG_label (0xa) @ <0x97> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0xbd> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0xed> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0x109> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0x12a> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0x146> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0x16f> not handled! > ... > > Is this a problem with LLVM or pahole? I do not see this when building > with GCC + GNU as but that could just be a red herring. I assume that > there could be something missing for processing debug info from > assembly, perhaps? If there is any further information I can provide or > anything I can test, I am more than happy to do so. I'll try to repro, but at first sight it looks like a label in a DW_TAG_compile_unit/like level, I have to check what that means, but seems to be just a warning, did the end result made sense? - Arnaldo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-27 19:08 ` Arnaldo Carvalho de Melo @ 2022-09-27 19:59 ` Nathan Chancellor 2022-09-28 13:42 ` Arnaldo Carvalho de Melo 0 siblings, 1 reply; 12+ messages in thread From: Nathan Chancellor @ 2022-09-27 19:59 UTC (permalink / raw) To: Arnaldo Carvalho de Melo; +Cc: Nick Desaulniers, dwarves, llvm On Tue, Sep 27, 2022 at 04:08:02PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Sep 27, 2022 at 11:56:34AM -0700, Nathan Chancellor escreveu: > > Hi Arnaldo, > > > > When building a kernel with LLVM and CONFIG_DEBUG_INFO_BTF after commit > > 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") in > > the kernel, I see the following spew of warnings, which appear to come > > from pahole: > > > > $ clang --version > > clang version 15.0.0 (Fedora 15.0.0-3.fc38) > > Target: x86_64-redhat-linux-gnu > > Thread model: posix > > InstalledDir: /usr/bin > > > > $ pahole --version > > v1.24 > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig > > > > $ scripts/config \ > > -d DEBUG_INFO_NONE \ > > -e BPF_SYSCALL \ > > -e DEBUG_INFO_BTF \ > > -e DEBUG_INFO_DWARF5 > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all > > ... > > die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! > > die__process_unit: tag not supported 0xa (label)! > > die__process_unit: DW_TAG_label (0xa) @ <0x97> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0xbd> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0xed> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0x109> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0x12a> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0x146> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0x16f> not handled! > > ... > > > > Is this a problem with LLVM or pahole? I do not see this when building > > with GCC + GNU as but that could just be a red herring. I assume that > > there could be something missing for processing debug info from > > assembly, perhaps? If there is any further information I can provide or > > anything I can test, I am more than happy to do so. > > I'll try to repro, but at first sight it looks like a label in a If you need help reproducing this locally, feel free to reach out through this thread or #clangbuiltlinux on Libera. > DW_TAG_compile_unit/like level, I have to check what that means, but > seems to be just a warning, did the end result made sense? Right, this appears to just be a warning, the build still completes successfully (I did not check much else). I only noticed this by scrolling back in my build logs. Cheers, Nathan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-27 19:59 ` Nathan Chancellor @ 2022-09-28 13:42 ` Arnaldo Carvalho de Melo 2022-09-28 15:25 ` Nathan Chancellor 0 siblings, 1 reply; 12+ messages in thread From: Arnaldo Carvalho de Melo @ 2022-09-28 13:42 UTC (permalink / raw) To: Nathan Chancellor; +Cc: Nick Desaulniers, dwarves, llvm Em Tue, Sep 27, 2022 at 12:59:03PM -0700, Nathan Chancellor escreveu: > On Tue, Sep 27, 2022 at 04:08:02PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Tue, Sep 27, 2022 at 11:56:34AM -0700, Nathan Chancellor escreveu: > > > Hi Arnaldo, > > > > > > When building a kernel with LLVM and CONFIG_DEBUG_INFO_BTF after commit > > > 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") in > > > the kernel, I see the following spew of warnings, which appear to come > > > from pahole: > > > > > > $ clang --version > > > clang version 15.0.0 (Fedora 15.0.0-3.fc38) > > > Target: x86_64-redhat-linux-gnu > > > Thread model: posix > > > InstalledDir: /usr/bin > > > > > > $ pahole --version > > > v1.24 > > > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig > > > > > > $ scripts/config \ > > > -d DEBUG_INFO_NONE \ > > > -e BPF_SYSCALL \ > > > -e DEBUG_INFO_BTF \ > > > -e DEBUG_INFO_DWARF5 > > > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all > > > ... > > > die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! > > > die__process_unit: tag not supported 0xa (label)! > > > die__process_unit: DW_TAG_label (0xa) @ <0x97> not handled! > > > die__process_unit: DW_TAG_label (0xa) @ <0xbd> not handled! > > > die__process_unit: DW_TAG_label (0xa) @ <0xed> not handled! > > > die__process_unit: DW_TAG_label (0xa) @ <0x109> not handled! > > > die__process_unit: DW_TAG_label (0xa) @ <0x12a> not handled! > > > die__process_unit: DW_TAG_label (0xa) @ <0x146> not handled! > > > die__process_unit: DW_TAG_label (0xa) @ <0x16f> not handled! > > > ... > > > > > > Is this a problem with LLVM or pahole? I do not see this when building > > > with GCC + GNU as but that could just be a red herring. I assume that > > > there could be something missing for processing debug info from > > > assembly, perhaps? If there is any further information I can provide or > > > anything I can test, I am more than happy to do so. > > > > I'll try to repro, but at first sight it looks like a label in a > > If you need help reproducing this locally, feel free to reach out > through this thread or #clangbuiltlinux on Libera. Can you please provide the vmlinux file where this takes place? > > DW_TAG_compile_unit/like level, I have to check what that means, but > > seems to be just a warning, did the end result made sense? > > Right, this appears to just be a warning, the build still completes > successfully (I did not check much else). I only noticed this by > scrolling back in my build logs. Ok. - Arnaldo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-28 13:42 ` Arnaldo Carvalho de Melo @ 2022-09-28 15:25 ` Nathan Chancellor 2022-09-29 1:03 ` Arnaldo Carvalho de Melo 2022-09-29 12:42 ` BTF: A fix and more work to do :Re: " Arnaldo Carvalho de Melo 0 siblings, 2 replies; 12+ messages in thread From: Nathan Chancellor @ 2022-09-28 15:25 UTC (permalink / raw) To: Arnaldo Carvalho de Melo; +Cc: Nick Desaulniers, dwarves, llvm On Wed, Sep 28, 2022 at 10:42:53AM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Sep 27, 2022 at 12:59:03PM -0700, Nathan Chancellor escreveu: > > On Tue, Sep 27, 2022 at 04:08:02PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Tue, Sep 27, 2022 at 11:56:34AM -0700, Nathan Chancellor escreveu: > > > > Hi Arnaldo, > > > > > > > > When building a kernel with LLVM and CONFIG_DEBUG_INFO_BTF after commit > > > > 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") in > > > > the kernel, I see the following spew of warnings, which appear to come > > > > from pahole: > > > > > > > > $ clang --version > > > > clang version 15.0.0 (Fedora 15.0.0-3.fc38) > > > > Target: x86_64-redhat-linux-gnu > > > > Thread model: posix > > > > InstalledDir: /usr/bin > > > > > > > > $ pahole --version > > > > v1.24 > > > > > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig > > > > > > > > $ scripts/config \ > > > > -d DEBUG_INFO_NONE \ > > > > -e BPF_SYSCALL \ > > > > -e DEBUG_INFO_BTF \ > > > > -e DEBUG_INFO_DWARF5 > > > > > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all > > > > ... > > > > die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! > > > > die__process_unit: tag not supported 0xa (label)! > > > > die__process_unit: DW_TAG_label (0xa) @ <0x97> not handled! > > > > die__process_unit: DW_TAG_label (0xa) @ <0xbd> not handled! > > > > die__process_unit: DW_TAG_label (0xa) @ <0xed> not handled! > > > > die__process_unit: DW_TAG_label (0xa) @ <0x109> not handled! > > > > die__process_unit: DW_TAG_label (0xa) @ <0x12a> not handled! > > > > die__process_unit: DW_TAG_label (0xa) @ <0x146> not handled! > > > > die__process_unit: DW_TAG_label (0xa) @ <0x16f> not handled! > > > > ... > > > > > > > > Is this a problem with LLVM or pahole? I do not see this when building > > > > with GCC + GNU as but that could just be a red herring. I assume that > > > > there could be something missing for processing debug info from > > > > assembly, perhaps? If there is any further information I can provide or > > > > anything I can test, I am more than happy to do so. > > > > > > I'll try to repro, but at first sight it looks like a label in a > > > > If you need help reproducing this locally, feel free to reach out > > through this thread or #clangbuiltlinux on Libera. > > Can you please provide the vmlinux file where this takes place? Sure thing, it is compressed to save some bandwidth while downloading: https://1drv.ms/u/s!AsQNYeB-IEbqnnzsULjM1pXmOlI5?e=qHKjuW If there is anything else I can provide, please let me know! Cheers, Nathan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-28 15:25 ` Nathan Chancellor @ 2022-09-29 1:03 ` Arnaldo Carvalho de Melo 2022-09-29 12:42 ` BTF: A fix and more work to do :Re: " Arnaldo Carvalho de Melo 1 sibling, 0 replies; 12+ messages in thread From: Arnaldo Carvalho de Melo @ 2022-09-29 1:03 UTC (permalink / raw) To: Nathan Chancellor; +Cc: Nick Desaulniers, dwarves, llvm Em Wed, Sep 28, 2022 at 08:25:51AM -0700, Nathan Chancellor escreveu: > On Wed, Sep 28, 2022 at 10:42:53AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Tue, Sep 27, 2022 at 12:59:03PM -0700, Nathan Chancellor escreveu: > > > On Tue, Sep 27, 2022 at 04:08:02PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Tue, Sep 27, 2022 at 11:56:34AM -0700, Nathan Chancellor escreveu: > > > > > When building a kernel with LLVM and CONFIG_DEBUG_INFO_BTF after commit > > > > > 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") in > > > > > the kernel, I see the following spew of warnings, which appear to come > > > > > from pahole: > > > > > > > > > > $ clang --version > > > > > clang version 15.0.0 (Fedora 15.0.0-3.fc38) > > > > > Target: x86_64-redhat-linux-gnu > > > > > Thread model: posix > > > > > InstalledDir: /usr/bin > > > > > > > > > > $ pahole --version > > > > > v1.24 > > > > > > > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig > > > > > > > > > > $ scripts/config \ > > > > > -d DEBUG_INFO_NONE \ > > > > > -e BPF_SYSCALL \ > > > > > -e DEBUG_INFO_BTF \ > > > > > -e DEBUG_INFO_DWARF5 > > > > > > > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all > > > > > ... > > > > > die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! > > > > > die__process_unit: tag not supported 0xa (label)! > > > > > die__process_unit: DW_TAG_label (0xa) @ <0x97> not handled! > > > > > die__process_unit: DW_TAG_label (0xa) @ <0xbd> not handled! > > > > > die__process_unit: DW_TAG_label (0xa) @ <0xed> not handled! > > > > > die__process_unit: DW_TAG_label (0xa) @ <0x109> not handled! > > > > > die__process_unit: DW_TAG_label (0xa) @ <0x12a> not handled! > > > > > die__process_unit: DW_TAG_label (0xa) @ <0x146> not handled! > > > > > die__process_unit: DW_TAG_label (0xa) @ <0x16f> not handled! > > > > > ... > > > > > > > > > > Is this a problem with LLVM or pahole? I do not see this when building > > > > > with GCC + GNU as but that could just be a red herring. I assume that > > > > > there could be something missing for processing debug info from > > > > > assembly, perhaps? If there is any further information I can provide or > > > > > anything I can test, I am more than happy to do so. > > > > > > > > I'll try to repro, but at first sight it looks like a label in a > > > > > > If you need help reproducing this locally, feel free to reach out > > > through this thread or #clangbuiltlinux on Libera. > > > > Can you please provide the vmlinux file where this takes place? > > Sure thing, it is compressed to save some bandwidth while downloading: > > https://1drv.ms/u/s!AsQNYeB-IEbqnnzsULjM1pXmOlI5?e=qHKjuW > > If there is anything else I can provide, please let me know! Interesting, indeed it is inside a DW_TAG_compile_unit, outside functions, so pahole has no use for it right now, I'll just ignore it and remove that warning. These are for arch/x86/kernel/verify_cpu.S, asm file indeed. ⬢[acme@toolbox Nathan]$ readelf -wi vmlinux-pahole-warnings Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length: 0x1df (32-bit) Version: 5 Unit Type: DW_UT_compile (1) Abbrev Offset: 0x0 Pointer Size: 8 <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit) <d> DW_AT_stmt_list : 0x0 <11> DW_AT_ranges : 0xc <15> DW_AT_name : arch/x86/kernel/verify_cpu.S <32> DW_AT_comp_dir : /home/nathan/cbl/src/linux <4d> DW_AT_producer : ClangBuiltLinux clang version 16.0.0 (https://github.com/llvm/llvm-project 7e22179d38c438fedb0d9bb0cff1585843bd7082) <c2> DW_AT_language : 32769 (MIPS assembler) <1><c4>: Abbrev Number: 2 (DW_TAG_label) <c5> DW_AT_name : startup_64 <d0> DW_AT_decl_file : 0x0 <d4> DW_AT_decl_line : 0x364 <d8> DW_AT_low_pc : 0xffffffff81000000 <1><e0>: Abbrev Number: 2 (DW_TAG_label) <e1> DW_AT_name : secondary_startup_64 <f6> DW_AT_decl_file : 0x0 <fa> DW_AT_decl_line : 0x399 <fe> DW_AT_low_pc : 0xffffffff81000060 <1><106>: Abbrev Number: 2 (DW_TAG_label) <107> DW_AT_name : secondary_startup_64_no_verify <126> DW_AT_decl_file : 0x0 <12a> DW_AT_decl_line : 0x39f <12e> DW_AT_low_pc : 0xffffffff81000065 <1><136>: Abbrev Number: 2 (DW_TAG_label) <137> DW_AT_name : verify_cpu <142> DW_AT_decl_file : 0x0 <146> DW_AT_decl_line : 0x430 <14a> DW_AT_low_pc : 0xffffffff81000150 <1><152>: Abbrev Number: 2 (DW_TAG_label) <153> DW_AT_name : sev_verify_cbit <163> DW_AT_decl_file : 0x1 <167> DW_AT_decl_line : 0x491 <16b> DW_AT_low_pc : 0xffffffff81000250 <1><173>: Abbrev Number: 2 (DW_TAG_label) <174> DW_AT_name : start_cpu0 <17f> DW_AT_decl_file : 0x2 <183> DW_AT_decl_line : 0x49e <187> DW_AT_low_pc : 0xffffffff81000260 <1><18f>: Abbrev Number: 2 (DW_TAG_label) <190> DW_AT_name : early_idt_handler_array <1a8> DW_AT_decl_file : 0x0 <1ac> DW_AT_decl_line : 0x4ad <1b0> DW_AT_low_pc : 0xffffffff83796000 <1><1b8>: Abbrev Number: 2 (DW_TAG_label) <1b9> DW_AT_name : early_idt_handler_common <1d2> DW_AT_decl_file : 0x0 <1d6> DW_AT_decl_line : 0x4c1 <1da> DW_AT_low_pc : 0xffffffff83796120 <BIG SNIP> ^ permalink raw reply [flat|nested] 12+ messages in thread
* BTF: A fix and more work to do :Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-28 15:25 ` Nathan Chancellor 2022-09-29 1:03 ` Arnaldo Carvalho de Melo @ 2022-09-29 12:42 ` Arnaldo Carvalho de Melo 2022-09-29 12:50 ` Arnaldo Carvalho de Melo 2022-09-29 19:33 ` Arnaldo Carvalho de Melo 1 sibling, 2 replies; 12+ messages in thread From: Arnaldo Carvalho de Melo @ 2022-09-29 12:42 UTC (permalink / raw) To: Nathan Chancellor, Yonghong Song; +Cc: Nick Desaulniers, dwarves, llvm Em Wed, Sep 28, 2022 at 08:25:51AM -0700, Nathan Chancellor escreveu: > On Wed, Sep 28, 2022 at 10:42:53AM -0300, Arnaldo Carvalho de Melo wrote: > > Can you please provide the vmlinux file where this takes place? > > Sure thing, it is compressed to save some bandwidth while downloading: > > https://1drv.ms/u/s!AsQNYeB-IEbqnnzsULjM1pXmOlI5?e=qHKjuW So, fixed the case reported, DW_TAG_label outside a DW_TAG_lexblock, on asm DW_TAG_compile_unit DWARF containers, now I noticed that pahole suports encoding BTF_KIND_TAG (18) but not _decoding_ those, so off I go to work on it on btf_loader.c, looking at what btf_encoder.c does. Good that you got me this vmlinux built by clang 15 :-) Now we can BTF encode a vmlinux (-J) using all the CPUs in the system (-j), and then we end up with a kernel with BTF_KIND_TAG that can't be properly grokked by pahole when loading from BTF: ⬢[acme@toolbox pahole]$ pahole -j -J vmlinux-pahole-warnings ⬢[acme@toolbox pahole]$ pahole -F btf vmlinux-pahole-warnings > pahole-pretty-printed-from-btf BTF: idx: 277, Unknown kind 18 BTF: idx: 281, Unknown kind 18 BTF: idx: 331, Unknown kind 18 BTF: idx: 689, Unknown kind 18 BTF: idx: 692, Unknown kind 18 For instance: ⬢[acme@toolbox pahole]$ pahole -C __sifields -F btf vmlinux-pahole-warnings BTF: idx: 277, Unknown kind 18 BTF: idx: 281, Unknown kind 18 BTF: idx: 331, Unknown kind 18 BTF: idx: 689, Unknown kind 18 <BIG SNIP> BTF: idx: 128403, Unknown kind 18 BTF: idx: 128409, Unknown kind 18 union __sifields { struct { __kernel_pid_t _pid; /* 0 4 */ __kernel_uid32_t _uid; /* 4 4 */ } _kill; /* 0 8 */ struct { __kernel_timer_t _tid; /* 0 4 */ int _overrun; /* 4 4 */ sigval_t _sigval; /* 8 8 */ int _sys_private; /* 16 4 */ } _timer; /* 0 24 */ struct { __kernel_pid_t _pid; /* 0 4 */ __kernel_uid32_t _uid; /* 4 4 */ sigval_t _sigval; /* 8 8 */ } _rt; /* 0 16 */ struct { __kernel_pid_t _pid; /* 0 4 */ __kernel_uid32_t _uid; /* 4 4 */ int _status; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ __kernel_clock_t _utime; /* 16 8 */ __kernel_clock_t _stime; /* 24 8 */ } _sigchld; /* 0 32 */ struct { <ERROR > _addr; /* 0 8 */ union { int _trapno; /* 8 4 */ short _addr_lsb; /* 8 2 */ struct { char _dummy_bnd[8]; /* 8 8 */ <ERROR> _lower; /* 16 8 */ <ERROR> _upper; /* 24 8 */ } _addr_bnd; /* 8 24 */ struct { char _dummy_pkey[8]; /* 8 8 */ __u32 _pkey; /* 16 4 */ } _addr_pkey; /* 8 12 */ struct { unsigned long _data; /* 8 8 */ __u32 _type; /* 16 4 */ __u32 _flags; /* 20 4 */ } _perf; /* 8 16 */ }; /* 8 24 */ } _sigfault; /* 0 32 */ struct { long _band; /* 0 8 */ int _fd; /* 8 4 */ } _sigpoll; /* 0 16 */ struct { <ERROR > _call_addr; /* 0 8 */ int _syscall; /* 8 4 */ unsigned int _arch; /* 12 4 */ } _sigsys; /* 0 16 */ }; ⬢[acme@toolbox pahole]$ And if we look from DWARF: ⬢[acme@toolbox pahole]$ pahole -C __sifields -F dwarf vmlinux-pahole-warnings | grep -w _addr -B2 -A2 } _sigchld; /* 0 32 */ struct { user * _addr; /* 0 8 */ union { int _trapno; /* 8 4 */ ⬢[acme@toolbox pahole]$ And from the source code: /* SIGILL, SIGFPE, SIGSEGV, SIGBUS, SIGTRAP, SIGEMT */ struct { void __user *_addr; /* faulting insn/memory ref. */ #ifdef __ia64__ int _imm; /* immediate value for "break" */ unsigned int _flags; /* see ia64 si_flags */ unsigned long _isr; /* isr */ #endif #define __ADDR_BND_PKEY_PAD (__alignof__(void *) < sizeof(short) ? \ sizeof(short) : __alignof__(void *)) union { /* used on alpha and sparc */ int _trapno; /* TRAP # which caused the signal */ /* * used when si_code=BUS_MCEERR_AR or * used when si_code=BUS_MCEERR_AO */ short _addr_lsb; /* LSB of the reported address */ /* used when si_code=SEGV_BNDERR */ struct { char _dummy_bnd[__ADDR_BND_PKEY_PAD]; void __user *_lower; void __user *_upper; } _addr_bnd; Ok: # define __user BTF_TYPE_TAG(user) #if defined(CONFIG_DEBUG_INFO_BTF) && defined(CONFIG_PAHOLE_HAS_BTF_TAG) && \ __has_attribute(btf_type_tag) # define BTF_TYPE_TAG(value) __attribute__((btf_type_tag(#value))) #else # define BTF_TYPE_TAG(value) /* nothing */ #endif Ok, homework to do: we need to better support btf_type_tag in both pahole pretty printer and in its BTF loader. :-) One of the new features will be: pahole --types_with_user_members - Arnaldo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: BTF: A fix and more work to do :Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-29 12:42 ` BTF: A fix and more work to do :Re: " Arnaldo Carvalho de Melo @ 2022-09-29 12:50 ` Arnaldo Carvalho de Melo 2022-09-29 19:33 ` Arnaldo Carvalho de Melo 1 sibling, 0 replies; 12+ messages in thread From: Arnaldo Carvalho de Melo @ 2022-09-29 12:50 UTC (permalink / raw) To: Nathan Chancellor, Yonghong Song; +Cc: Nick Desaulniers, dwarves, llvm Em Thu, Sep 29, 2022 at 09:42:53AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Sep 28, 2022 at 08:25:51AM -0700, Nathan Chancellor escreveu: > > On Wed, Sep 28, 2022 at 10:42:53AM -0300, Arnaldo Carvalho de Melo wrote: > > > Can you please provide the vmlinux file where this takes place? > > Sure thing, it is compressed to save some bandwidth while downloading: > > https://1drv.ms/u/s!AsQNYeB-IEbqnnzsULjM1pXmOlI5?e=qHKjuW > So, fixed the case reported, DW_TAG_label outside a DW_TAG_lexblock, on > asm DW_TAG_compile_unit DWARF containers, ... Forgot the patch: From f01e5f3a849558b8ed6b310686d10738f4c2f3bf Mon Sep 17 00:00:00 2001 From: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Thu, 29 Sep 2022 09:43:16 -0300 Subject: [PATCH 1/1] dwarf_loader: Support DW_TAG_label outside DW_TAG_lexblock This happens with asm CUs, noticed when building the Linux kernel with clang 15, where we have, for instance: Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length: 0x1df (32-bit) Version: 5 Unit Type: DW_UT_compile (1) Abbrev Offset: 0x0 Pointer Size: 8 <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit) <d> DW_AT_stmt_list : 0x0 <11> DW_AT_ranges : 0xc <15> DW_AT_name : arch/x86/kernel/verify_cpu.S <32> DW_AT_comp_dir : /home/nathan/cbl/src/linux <4d> DW_AT_producer : ClangBuiltLinux clang version 16.0.0 (https://github.com/llvm/llvm-project 7e22179d38c438fedb0d9bb0cff1585843bd7082) <c2> DW_AT_language : 32769 (MIPS assembler) <1><c4>: Abbrev Number: 2 (DW_TAG_label) <c5> DW_AT_name : startup_64 <d0> DW_AT_decl_file : 0x0 <d4> DW_AT_decl_line : 0x364 <d8> DW_AT_low_pc : 0xffffffff81000000 <1><e0>: Abbrev Number: 2 (DW_TAG_label) <e1> DW_AT_name : secondary_startup_64 <f6> DW_AT_decl_file : 0x0 <fa> DW_AT_decl_line : 0x399 <fe> DW_AT_low_pc : 0xffffffff81000060 <1><106>: Abbrev Number: 2 (DW_TAG_label) <107> DW_AT_name : secondary_startup_64_no_verify <126> DW_AT_decl_file : 0x0 <12a> DW_AT_decl_line : 0x39f <12e> DW_AT_low_pc : 0xffffffff81000065 <1><136>: Abbrev Number: 2 (DW_TAG_label) <137> DW_AT_name : verify_cpu <142> DW_AT_decl_file : 0x0 <146> DW_AT_decl_line : 0x430 <14a> DW_AT_low_pc : 0xffffffff81000150 <SNIP> Reported-by: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/dwarves/YzWSzXKcm6rSWOC5@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> --- dwarf_loader.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/dwarf_loader.c b/dwarf_loader.c index 631bbd434eb2a4e6..28a912ec725a6e68 100644 --- a/dwarf_loader.c +++ b/dwarf_loader.c @@ -1485,7 +1485,12 @@ static struct tag *die__create_new_label(Dwarf_Die *die, if (label == NULL) return NULL; - lexblock__add_label(lexblock, label); + if (lexblock != NULL) { + // asm CUs have labels and they will be in the cu top level tag list + // See die__process_unit() + lexblock__add_label(lexblock, label); + } + return &label->ip.tag; } @@ -2037,6 +2042,12 @@ static struct tag *__die__process_tag(Dwarf_Die *die, struct cu *cu, */ tag = &unsupported_tag; break; + case DW_TAG_label: + if (conf->ignore_labels) + tag = &unsupported_tag; // callers will assume conf->ignore_labels is true + else // We can have labels in asm CUs, no lexblock + tag = die__create_new_label(die, NULL, cu, conf); + break; } if (tag != NULL) @@ -2055,7 +2066,8 @@ static int die__process_unit(Dwarf_Die *die, struct cu *cu, struct conf_load *co if (tag == &unsupported_tag) { // XXX special case DW_TAG_dwarf_procedure, appears when looking at a recent ~/bin/perf // Investigate later how to properly support this... - if (dwarf_tag(die) != DW_TAG_dwarf_procedure) + if (dwarf_tag(die) != DW_TAG_dwarf_procedure && + dwarf_tag(die) != DW_TAG_label) // conf->ignore_labels == true, see die__process_tag() tag__print_not_supported(dwarf_tag(die)); continue; } -- 2.37.3 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: BTF: A fix and more work to do :Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-29 12:42 ` BTF: A fix and more work to do :Re: " Arnaldo Carvalho de Melo 2022-09-29 12:50 ` Arnaldo Carvalho de Melo @ 2022-09-29 19:33 ` Arnaldo Carvalho de Melo 2022-10-07 23:32 ` Yonghong Song 1 sibling, 1 reply; 12+ messages in thread From: Arnaldo Carvalho de Melo @ 2022-09-29 19:33 UTC (permalink / raw) To: Yonghong Song, Nathan Chancellor; +Cc: Nick Desaulniers, dwarves, llvm Em Thu, Sep 29, 2022 at 09:42:53AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Sep 28, 2022 at 08:25:51AM -0700, Nathan Chancellor escreveu: > > On Wed, Sep 28, 2022 at 10:42:53AM -0300, Arnaldo Carvalho de Melo wrote: > > > Can you please provide the vmlinux file where this takes place? > > > > Sure thing, it is compressed to save some bandwidth while downloading: > > > > https://1drv.ms/u/s!AsQNYeB-IEbqnnzsULjM1pXmOlI5?e=qHKjuW > > So, fixed the case reported, DW_TAG_label outside a DW_TAG_lexblock, on > asm DW_TAG_compile_unit DWARF containers, now I noticed that pahole > suports encoding BTF_KIND_TAG (18) but not _decoding_ those, so off I go > to work on it on btf_loader.c, looking at what btf_encoder.c does. > > Good that you got me this vmlinux built by clang 15 :-) > > Now we can BTF encode a vmlinux (-J) using all the CPUs in the system > (-j), and then we end up with a kernel with BTF_KIND_TAG that can't be > properly grokked by pahole when loading from BTF: > > ⬢[acme@toolbox pahole]$ pahole -j -J vmlinux-pahole-warnings > ⬢[acme@toolbox pahole]$ pahole -F btf vmlinux-pahole-warnings > pahole-pretty-printed-from-btf > BTF: idx: 277, Unknown kind 18 > BTF: idx: 281, Unknown kind 18 > BTF: idx: 331, Unknown kind 18 > BTF: idx: 689, Unknown kind 18 > BTF: idx: 692, Unknown kind 18 > > For instance: > > ⬢[acme@toolbox pahole]$ pahole -C __sifields -F btf vmlinux-pahole-warnings > BTF: idx: 277, Unknown kind 18 > BTF: idx: 281, Unknown kind 18 > BTF: idx: 331, Unknown kind 18 > BTF: idx: 689, Unknown kind 18 > <BIG SNIP> > BTF: idx: 128403, Unknown kind 18 > BTF: idx: 128409, Unknown kind 18 > union __sifields { > struct { > __kernel_pid_t _pid; /* 0 4 */ > __kernel_uid32_t _uid; /* 4 4 */ > } _kill; /* 0 8 */ > struct { > __kernel_timer_t _tid; /* 0 4 */ > int _overrun; /* 4 4 */ > sigval_t _sigval; /* 8 8 */ > int _sys_private; /* 16 4 */ > } _timer; /* 0 24 */ > struct { > __kernel_pid_t _pid; /* 0 4 */ > __kernel_uid32_t _uid; /* 4 4 */ > sigval_t _sigval; /* 8 8 */ > } _rt; /* 0 16 */ > struct { > __kernel_pid_t _pid; /* 0 4 */ > __kernel_uid32_t _uid; /* 4 4 */ > int _status; /* 8 4 */ > > /* XXX 4 bytes hole, try to pack */ > > __kernel_clock_t _utime; /* 16 8 */ > __kernel_clock_t _stime; /* 24 8 */ > } _sigchld; /* 0 32 */ > struct { > <ERROR > _addr; /* 0 8 */ So this shares a type with several other fields/variables/whatever and then: [ cb57] member abbrev: 6 name (strx2) "sival_ptr" type (ref4) [ cb62] decl_file (data1) siginfo.h (153) decl_line (data1) 10 data_member_location (data1) 0 [ cb62] pointer_type abbrev: 80 [ cb63] lo_user+0x1f80 abbrev: 51 name (strx1) "btf_type_tag" const_value (strx1) "user" This is with eu-readelf from elfutils, binutils readelf gets confused, unsure about the equivalent for llvm, lets see: llvm-dwarfdump gets: 0x0000cb57: DW_TAG_member DW_AT_name ("sival_ptr") DW_AT_type (0x0000cb62 "void *") DW_AT_decl_file ("/home/nathan/cbl/src/linux/./include/uapi/asm-generic/siginfo.h") DW_AT_decl_line (10) DW_AT_data_member_location (0x00) looks saner, a void pointer, probably with an attribute of btf_type_tag (DW_TAG_llvm-something, IIRC): 0x0000cb62: DW_TAG_pointer_type 0x0000cb63: DW_TAG_LLVM_annotation DW_AT_name ("btf_type_tag") DW_AT_const_value ("user") 0x0000cb66: NULL None of these tools seem to be grokking this nicely, Yonghong? ⬢[acme@toolbox pahole]$ llvm-dwarfdump --version LLVM (http://llvm.org/): LLVM version 14.0.0git Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: znver3 ⬢[acme@toolbox pahole]$ cat /etc/fedora-release Fedora release 36 (Thirty Six) ⬢[acme@toolbox pahole]$ I.e. sival_ptr is a: typedef union sigval { int sival_int; void __user *sival_ptr; } sigval_t; So I would expect that sival_ptr pointed to a void * with an intermediate DW_TAG_LLVM_annotation? What is the semantics? How all these tools need to grok this? - Arnaldo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: BTF: A fix and more work to do :Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-29 19:33 ` Arnaldo Carvalho de Melo @ 2022-10-07 23:32 ` Yonghong Song 0 siblings, 0 replies; 12+ messages in thread From: Yonghong Song @ 2022-10-07 23:32 UTC (permalink / raw) To: Arnaldo Carvalho de Melo, Nathan Chancellor Cc: Nick Desaulniers, dwarves, llvm On 9/29/22 12:33 PM, Arnaldo Carvalho de Melo wrote: > Em Thu, Sep 29, 2022 at 09:42:53AM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Wed, Sep 28, 2022 at 08:25:51AM -0700, Nathan Chancellor escreveu: >>> On Wed, Sep 28, 2022 at 10:42:53AM -0300, Arnaldo Carvalho de Melo wrote: >>>> Can you please provide the vmlinux file where this takes place? >>> >>> Sure thing, it is compressed to save some bandwidth while downloading: >>> >>> https://1drv.ms/u/s!AsQNYeB-IEbqnnzsULjM1pXmOlI5?e=qHKjuW >> >> So, fixed the case reported, DW_TAG_label outside a DW_TAG_lexblock, on >> asm DW_TAG_compile_unit DWARF containers, now I noticed that pahole >> suports encoding BTF_KIND_TAG (18) but not _decoding_ those, so off I go >> to work on it on btf_loader.c, looking at what btf_encoder.c does. >> >> Good that you got me this vmlinux built by clang 15 :-) >> >> Now we can BTF encode a vmlinux (-J) using all the CPUs in the system >> (-j), and then we end up with a kernel with BTF_KIND_TAG that can't be >> properly grokked by pahole when loading from BTF: >> >> ⬢[acme@toolbox pahole]$ pahole -j -J vmlinux-pahole-warnings >> ⬢[acme@toolbox pahole]$ pahole -F btf vmlinux-pahole-warnings > pahole-pretty-printed-from-btf >> BTF: idx: 277, Unknown kind 18 >> BTF: idx: 281, Unknown kind 18 >> BTF: idx: 331, Unknown kind 18 >> BTF: idx: 689, Unknown kind 18 >> BTF: idx: 692, Unknown kind 18 >> >> For instance: >> >> ⬢[acme@toolbox pahole]$ pahole -C __sifields -F btf vmlinux-pahole-warnings >> BTF: idx: 277, Unknown kind 18 >> BTF: idx: 281, Unknown kind 18 >> BTF: idx: 331, Unknown kind 18 >> BTF: idx: 689, Unknown kind 18 >> <BIG SNIP> >> BTF: idx: 128403, Unknown kind 18 >> BTF: idx: 128409, Unknown kind 18 >> union __sifields { >> struct { >> __kernel_pid_t _pid; /* 0 4 */ >> __kernel_uid32_t _uid; /* 4 4 */ >> } _kill; /* 0 8 */ >> struct { >> __kernel_timer_t _tid; /* 0 4 */ >> int _overrun; /* 4 4 */ >> sigval_t _sigval; /* 8 8 */ >> int _sys_private; /* 16 4 */ >> } _timer; /* 0 24 */ >> struct { >> __kernel_pid_t _pid; /* 0 4 */ >> __kernel_uid32_t _uid; /* 4 4 */ >> sigval_t _sigval; /* 8 8 */ >> } _rt; /* 0 16 */ >> struct { >> __kernel_pid_t _pid; /* 0 4 */ >> __kernel_uid32_t _uid; /* 4 4 */ >> int _status; /* 8 4 */ >> >> /* XXX 4 bytes hole, try to pack */ >> >> __kernel_clock_t _utime; /* 16 8 */ >> __kernel_clock_t _stime; /* 24 8 */ >> } _sigchld; /* 0 32 */ >> struct { >> <ERROR > _addr; /* 0 8 */ > > So this shares a type with several other fields/variables/whatever and > then: > > [ cb57] member abbrev: 6 > name (strx2) "sival_ptr" > type (ref4) [ cb62] > decl_file (data1) siginfo.h (153) > decl_line (data1) 10 > data_member_location (data1) 0 > [ cb62] pointer_type abbrev: 80 > [ cb63] lo_user+0x1f80 abbrev: 51 > name (strx1) "btf_type_tag" > const_value (strx1) "user" > > > This is with eu-readelf from elfutils, binutils readelf gets confused, > unsure about the equivalent for llvm, lets see: > > llvm-dwarfdump gets: > > 0x0000cb57: DW_TAG_member > DW_AT_name ("sival_ptr") > DW_AT_type (0x0000cb62 "void *") > DW_AT_decl_file ("/home/nathan/cbl/src/linux/./include/uapi/asm-generic/siginfo.h") > DW_AT_decl_line (10) > DW_AT_data_member_location (0x00) > > looks saner, a void pointer, probably with an attribute of btf_type_tag > (DW_TAG_llvm-something, IIRC): > > 0x0000cb62: DW_TAG_pointer_type > > 0x0000cb63: DW_TAG_LLVM_annotation > DW_AT_name ("btf_type_tag") > DW_AT_const_value ("user") > > 0x0000cb66: NULL > > None of these tools seem to be grokking this nicely, Yonghong? Sorry for late reply. I missed this email. Yes, btf_type_tag is only supported with llvm. gcc/gnu-tools does not support it yet. There is an effort in gcc community to support this. https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598038.html but the progress has been slow recently. > > ⬢[acme@toolbox pahole]$ llvm-dwarfdump --version > LLVM (http://llvm.org/ ): > LLVM version 14.0.0git > Optimized build. > Default target: x86_64-unknown-linux-gnu > Host CPU: znver3 > ⬢[acme@toolbox pahole]$ cat /etc/fedora-release > Fedora release 36 (Thirty Six) > ⬢[acme@toolbox pahole]$ > > > I.e. sival_ptr is a: > > typedef union sigval { > int sival_int; > void __user *sival_ptr; > } sigval_t; > > So I would expect that sival_ptr pointed to a void * with an > intermediate DW_TAG_LLVM_annotation? What is the semantics? How all > these tools need to grok this? > > - Arnaldo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-27 18:56 die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! Nathan Chancellor 2022-09-27 19:08 ` Arnaldo Carvalho de Melo @ 2022-09-28 21:35 ` Nick Desaulniers 2022-09-29 0:57 ` Arnaldo Carvalho de Melo 1 sibling, 1 reply; 12+ messages in thread From: Nick Desaulniers @ 2022-09-28 21:35 UTC (permalink / raw) To: Arnaldo Carvalho de Melo; +Cc: dwarves, llvm, Nathan Chancellor On Tue, Sep 27, 2022 at 11:56 AM Nathan Chancellor <nathan@kernel.org> wrote: > > Hi Arnaldo, > > When building a kernel with LLVM and CONFIG_DEBUG_INFO_BTF after commit > 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") in > the kernel, I see the following spew of warnings, which appear to come > from pahole: > > $ clang --version > clang version 15.0.0 (Fedora 15.0.0-3.fc38) > Target: x86_64-redhat-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > > $ pahole --version > v1.24 > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig > > $ scripts/config \ > -d DEBUG_INFO_NONE \ > -e BPF_SYSCALL \ > -e DEBUG_INFO_BTF \ > -e DEBUG_INFO_DWARF5 > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all > ... > die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! > die__process_unit: tag not supported 0xa (label)! > die__process_unit: DW_TAG_label (0xa) @ <0x97> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0xbd> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0xed> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0x109> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0x12a> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0x146> not handled! > die__process_unit: DW_TAG_label (0xa) @ <0x16f> not handled! Running llvm-dwarfdump on vmlinux, I see: ``` $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all die__process_unit: DW_TAG_label (0xa) @ <0xbf> not handled! die__process_unit: tag not supported 0xa (label)! ... $ llvm-dwarfdump vmlinux | less ... 0x000000bf: DW_TAG_label DW_AT_name ("startup_64") DW_AT_decl_file ("/android0/kernel-all/arch/x86/kernel/head_64.S") DW_AT_decl_line (868) DW_AT_low_pc (0xffffffff81000000) 0x000000db: DW_TAG_label DW_AT_name ("secondary_startup_64") DW_AT_decl_file ("/android0/kernel-all/arch/x86/kernel/head_64.S") DW_AT_decl_line (921) DW_AT_low_pc (0xffffffff81000060) ... ``` So these seem to be labels in assembler sources. The DW_TAGs look the same to be for labels from C sources. > ... > > Is this a problem with LLVM or pahole? I do not see this when building > with GCC + GNU as but that could just be a red herring. I assume that > there could be something missing for processing debug info from > assembly, perhaps? That's what I suspect. > If there is any further information I can provide or > anything I can test, I am more than happy to do so. > > Cheers, > Nathan I swear I used to be able to build pahole from sources...just moved to a new machine and something seems off... $ sudo apt install libdwarf-dev libdw-dev $ git clone git://git.kernel.org/pub/scm/devel/pahole/pahole.git $ mkdir pahole/build $ cd !$ $ cmake -D__LIB=lib .. $ make ... [ 63%] Linking C executable codiff /usr/bin/ld: libdwarves.so.1.0.0: undefined reference to `dwfl_module_getelf' /usr/bin/ld: libdwarves.so.1.0.0: undefined reference to `dwfl_report_end' ... -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! 2022-09-28 21:35 ` Nick Desaulniers @ 2022-09-29 0:57 ` Arnaldo Carvalho de Melo 0 siblings, 0 replies; 12+ messages in thread From: Arnaldo Carvalho de Melo @ 2022-09-29 0:57 UTC (permalink / raw) To: Nick Desaulniers; +Cc: dwarves, llvm, Nathan Chancellor Em Wed, Sep 28, 2022 at 02:35:48PM -0700, Nick Desaulniers escreveu: > On Tue, Sep 27, 2022 at 11:56 AM Nathan Chancellor <nathan@kernel.org> wrote: > > > > Hi Arnaldo, > > > > When building a kernel with LLVM and CONFIG_DEBUG_INFO_BTF after commit > > 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") in > > the kernel, I see the following spew of warnings, which appear to come > > from pahole: > > > > $ clang --version > > clang version 15.0.0 (Fedora 15.0.0-3.fc38) > > Target: x86_64-redhat-linux-gnu > > Thread model: posix > > InstalledDir: /usr/bin > > > > $ pahole --version > > v1.24 > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig > > > > $ scripts/config \ > > -d DEBUG_INFO_NONE \ > > -e BPF_SYSCALL \ > > -e DEBUG_INFO_BTF \ > > -e DEBUG_INFO_DWARF5 > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all > > ... > > die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! > > die__process_unit: tag not supported 0xa (label)! > > die__process_unit: DW_TAG_label (0xa) @ <0x97> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0xbd> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0xed> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0x109> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0x12a> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0x146> not handled! > > die__process_unit: DW_TAG_label (0xa) @ <0x16f> not handled! > > Running llvm-dwarfdump on vmlinux, I see: > > ``` > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all > die__process_unit: DW_TAG_label (0xa) @ <0xbf> not handled! > die__process_unit: tag not supported 0xa (label)! > ... > $ llvm-dwarfdump vmlinux | less > ... > 0x000000bf: DW_TAG_label > DW_AT_name ("startup_64") > DW_AT_decl_file > ("/android0/kernel-all/arch/x86/kernel/head_64.S") > DW_AT_decl_line (868) > DW_AT_low_pc (0xffffffff81000000) > > 0x000000db: DW_TAG_label > DW_AT_name ("secondary_startup_64") > DW_AT_decl_file > ("/android0/kernel-all/arch/x86/kernel/head_64.S") > DW_AT_decl_line (921) > DW_AT_low_pc (0xffffffff81000060) > ... > ``` > > So these seem to be labels in assembler sources. The DW_TAGs look the > same to be for labels from C sources. Interesting, I think its just a matter of ignoring those when they appear on the DW_TAG_compile_unit then > > ... > > > > Is this a problem with LLVM or pahole? I do not see this when building > > with GCC + GNU as but that could just be a red herring. I assume that > > there could be something missing for processing debug info from > > assembly, perhaps? > > That's what I suspect. > > > If there is any further information I can provide or > > anything I can test, I am more than happy to do so. > > > > Cheers, > > Nathan > > I swear I used to be able to build pahole from sources...just moved to > a new machine and something seems off... > $ sudo apt install libdwarf-dev libdw-dev > $ git clone git://git.kernel.org/pub/scm/devel/pahole/pahole.git > $ mkdir pahole/build > $ cd !$ > $ cmake -D__LIB=lib .. > $ make > ... > [ 63%] Linking C executable codiff > /usr/bin/ld: libdwarves.so.1.0.0: undefined reference to `dwfl_module_getelf' > /usr/bin/ld: libdwarves.so.1.0.0: undefined reference to `dwfl_report_end' Strange, can you try without that -D__LIB=lib? here, fedora:37, in a toolbox: ⬢[acme@toolbox pahole]$ cd /tmp ⬢[acme@toolbox tmp]$ git clone git://git.kernel.org/pub/scm/devel/pahole/pahole.git Cloning into 'pahole'... remote: Enumerating objects: 24, done. remote: Counting objects: 100% (24/24), done. remote: Compressing objects: 100% (24/24), done. remote: Total 8346 (delta 8), reused 0 (delta 0), pack-reused 8322 Receiving objects: 100% (8346/8346), 2.14 MiB | 1.68 MiB/s, done. Resolving deltas: 100% (6008/6008), done. ⬢[acme@toolbox tmp]$ cd pahole/ ⬢[acme@toolbox pahole]$ mkdir build ⬢[acme@toolbox pahole]$ cd build ⬢[acme@toolbox build]$ cmake .. -- The C compiler identification is GNU 12.2.1 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/lib64/ccache/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Setting BUILD_SHARED_LIBS = ON -- Checking availability of DWARF and ELF development libraries -- Looking for dwfl_module_build_id in elf -- Looking for dwfl_module_build_id in elf - found -- Found dwarf.h header: /usr/include -- Found elfutils/libdw.h header: /usr/include -- Found libdw library: /usr/lib64/libdw.so -- Found libelf library: /usr/lib64/libelf.so -- Checking availability of DWARF and ELF development libraries - done -- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11") -- Checking availability of argp library -- Assuming argp is in libc -- Checking availability of argp library - done -- Checking availability of obstack library -- Assuming obstack is in libc -- Checking availability of obstack library - done -- Submodule update Submodule 'lib/bpf' (https://github.com/libbpf/libbpf) registered for path 'lib/bpf' Cloning into '/tmp/pahole/lib/bpf'... Submodule path 'lib/bpf': checked out '645500dd7d2d6b5bb76e4c0375d597d4f0c4814e' -- Submodule update - done -- Performing Test HAVE_REALLOCARRAY_SUPPORT -- Performing Test HAVE_REALLOCARRAY_SUPPORT - Success -- Configuring done -- Generating done -- Build files have been written to: /tmp/pahole/build ⬢[acme@toolbox build]$ cd .. ⬢[acme@toolbox pahole]$ make -C build make: Entering directory '/tmp/pahole/build' make[1]: Entering directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 1%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf.c.o [ 3%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf_prog_linfo.c.o [ 5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf.c.o [ 7%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf_dump.c.o [ 9%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/gen_loader.c.o [ 10%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/hashmap.c.o [ 12%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf.c.o [ 14%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_errno.c.o [ 16%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_probes.c.o [ 18%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/linker.c.o [ 20%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/netlink.c.o [ 21%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/nlattr.c.o [ 23%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/relo_core.c.o [ 25%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/ringbuf.c.o [ 27%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/str_error.c.o [ 29%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/strset.c.o [ 30%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/usdt.c.o [ 32%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/xsk.c.o make[2]: Leaving directory '/tmp/pahole/build' [ 32%] Built target bpf make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 34%] Building C object CMakeFiles/dwarves.dir/dwarves.c.o [ 36%] Building C object CMakeFiles/dwarves.dir/dwarves_fprintf.c.o [ 38%] Building C object CMakeFiles/dwarves.dir/gobuffer.c.o [ 40%] Building C object CMakeFiles/dwarves.dir/ctf_loader.c.o [ 41%] Building C object CMakeFiles/dwarves.dir/libctf.c.o [ 43%] Building C object CMakeFiles/dwarves.dir/btf_encoder.c.o [ 45%] Building C object CMakeFiles/dwarves.dir/btf_loader.c.o [ 47%] Building C object CMakeFiles/dwarves.dir/dwarf_loader.c.o [ 49%] Building C object CMakeFiles/dwarves.dir/dutil.c.o [ 50%] Building C object CMakeFiles/dwarves.dir/elf_symtab.c.o [ 52%] Building C object CMakeFiles/dwarves.dir/rbtree.c.o [ 54%] Linking C shared library libdwarves.so make[2]: Leaving directory '/tmp/pahole/build' [ 54%] Built target dwarves make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 56%] Building C object CMakeFiles/dwarves_emit.dir/dwarves_emit.c.o [ 58%] Linking C shared library libdwarves_emit.so make[2]: Leaving directory '/tmp/pahole/build' [ 58%] Built target dwarves_emit make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 60%] Building C object CMakeFiles/dwarves_reorganize.dir/dwarves_reorganize.c.o [ 61%] Linking C shared library libdwarves_reorganize.so make[2]: Leaving directory '/tmp/pahole/build' [ 61%] Built target dwarves_reorganize make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 63%] Building C object CMakeFiles/codiff.dir/codiff.c.o [ 65%] Linking C executable codiff make[2]: Leaving directory '/tmp/pahole/build' [ 65%] Built target codiff make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 67%] Building C object CMakeFiles/ctracer.dir/ctracer.c.o [ 69%] Linking C executable ctracer make[2]: Leaving directory '/tmp/pahole/build' [ 69%] Built target ctracer make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 70%] Building C object CMakeFiles/dtagnames.dir/dtagnames.c.o [ 72%] Linking C executable dtagnames make[2]: Leaving directory '/tmp/pahole/build' [ 72%] Built target dtagnames make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 74%] Building C object CMakeFiles/pahole.dir/pahole.c.o [ 76%] Linking C executable pahole make[2]: Leaving directory '/tmp/pahole/build' [ 76%] Built target pahole make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 78%] Building C object CMakeFiles/pdwtags.dir/pdwtags.c.o [ 80%] Linking C executable pdwtags make[2]: Leaving directory '/tmp/pahole/build' [ 80%] Built target pdwtags make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 81%] Building C object CMakeFiles/pglobal.dir/pglobal.c.o [ 83%] Linking C executable pglobal make[2]: Leaving directory '/tmp/pahole/build' [ 83%] Built target pglobal make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 85%] Building C object CMakeFiles/pfunct.dir/pfunct.c.o [ 87%] Linking C executable pfunct make[2]: Leaving directory '/tmp/pahole/build' [ 87%] Built target pfunct make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 89%] Building C object CMakeFiles/prefcnt.dir/prefcnt.c.o [ 90%] Linking C executable prefcnt make[2]: Leaving directory '/tmp/pahole/build' [ 90%] Built target prefcnt make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 92%] Building C object CMakeFiles/scncopy.dir/scncopy.c.o [ 94%] Building C object CMakeFiles/scncopy.dir/elfcreator.c.o [ 96%] Linking C executable scncopy make[2]: Leaving directory '/tmp/pahole/build' [ 96%] Built target scncopy make[2]: Entering directory '/tmp/pahole/build' make[2]: Leaving directory '/tmp/pahole/build' make[2]: Entering directory '/tmp/pahole/build' [ 98%] Building C object CMakeFiles/syscse.dir/syscse.c.o [100%] Linking C executable syscse make[2]: Leaving directory '/tmp/pahole/build' [100%] Built target syscse make[1]: Leaving directory '/tmp/pahole/build' make: Leaving directory '/tmp/pahole/build' ⬢[acme@toolbox pahole]$ rpm -qa | grep elfutils elfutils-debugsource-0.186-1.fc34.x86_64 elfutils-debuginfo-0.186-1.fc34.x86_64 elfutils-libs-debuginfo-0.186-1.fc34.x86_64 elfutils-libelf-0.187-4.fc36.x86_64 elfutils-libelf-devel-0.187-4.fc36.x86_64 elfutils-default-yama-scope-0.187-4.fc36.noarch elfutils-debuginfod-client-0.187-4.fc36.x86_64 elfutils-libs-0.187-4.fc36.x86_64 elfutils-0.187-4.fc36.x86_64 elfutils-debuginfod-client-devel-0.187-4.fc36.x86_64 elfutils-devel-0.187-4.fc36.x86_64 ⬢[acme@toolbox pahole]$ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-10-07 23:32 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-27 18:56 die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled! Nathan Chancellor 2022-09-27 19:08 ` Arnaldo Carvalho de Melo 2022-09-27 19:59 ` Nathan Chancellor 2022-09-28 13:42 ` Arnaldo Carvalho de Melo 2022-09-28 15:25 ` Nathan Chancellor 2022-09-29 1:03 ` Arnaldo Carvalho de Melo 2022-09-29 12:42 ` BTF: A fix and more work to do :Re: " Arnaldo Carvalho de Melo 2022-09-29 12:50 ` Arnaldo Carvalho de Melo 2022-09-29 19:33 ` Arnaldo Carvalho de Melo 2022-10-07 23:32 ` Yonghong Song 2022-09-28 21:35 ` Nick Desaulniers 2022-09-29 0:57 ` Arnaldo Carvalho de Melo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).