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
