Re: BTF: A fix and more work to do :Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled!

[Arnaldo Carvalho de Melo <acme@kernel.org>]

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