From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Yonghong Song <yhs@fb.com>, Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
dwarves@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: BTF: A fix and more work to do :Re: die__process_unit: DW_TAG_label (0xa) @ <0x7b> not handled!
Date: Thu, 29 Sep 2022 16:33:17 -0300 [thread overview]
Message-ID: <YzXy/birngORHLEd@kernel.org> (raw)
In-Reply-To: <YzWSzXKcm6rSWOC5@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
next prev parent reply other threads:[~2022-09-29 19:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2022-10-07 23:32 ` Yonghong Song
2022-09-28 21:35 ` Nick Desaulniers
2022-09-29 0:57 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YzXy/birngORHLEd@kernel.org \
--to=acme@kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).