All of lore.kernel.org
 help / color / mirror / Atom feed
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.