* 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-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
* 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
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).