From: Yonghong Song <yonghong.song@linux.dev>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Alan Maguire <alan.maguire@oracle.com>,
Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
dwarves@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com, Song Liu <song@kernel.org>
Subject: Re: [PATCH dwarves 3/3] dwarf_loader: Check DW_OP_[GNU_]entry_value for possible parameter matching
Date: Mon, 11 Nov 2024 10:54:56 -0800 [thread overview]
Message-ID: <b8aab7b4-c85f-40d3-bffb-44ab91b33abd@linux.dev> (raw)
In-Reply-To: <ZzHURz01dzLHO2H4@krava>
On 11/11/24 1:54 AM, Jiri Olsa wrote:
> On Fri, Nov 08, 2024 at 10:05:24AM -0800, Yonghong Song wrote:
>> Song Liu reported that a kernel func (perf_event_read()) cannot be traced
>> in certain situations since the func is not in vmlinux bTF. This happens
>> in kernels 6.4, 6.9 and 6.11 and the kernel is built with pahole 1.27.
>>
>> The perf_event_read() signature in kernel (kernel/events/core.c):
>> static int perf_event_read(struct perf_event *event, bool group)
>>
>> Adding '-V' to pahole command line, and the following error msg can be found:
>> skipping addition of 'perf_event_read'(perf_event_read) due to unexpected register used for parameter
>>
>> Eventually the error message is attributed to the setting
>> (parm->unexpected_reg = 1) in parameter__new() function.
>>
>> The following is the dwarf representation for perf_event_read():
>> 0x0334c034: DW_TAG_subprogram
>> DW_AT_low_pc (0xffffffff812c6110)
>> DW_AT_high_pc (0xffffffff812c640a)
>> DW_AT_frame_base (DW_OP_reg7 RSP)
>> DW_AT_GNU_all_call_sites (true)
>> DW_AT_name ("perf_event_read")
>> DW_AT_decl_file ("/rw/compile/kernel/events/core.c")
>> DW_AT_decl_line (4641)
>> DW_AT_prototyped (true)
>> DW_AT_type (0x03324f6a "int")
>> 0x0334c04e: DW_TAG_formal_parameter
>> DW_AT_location (0x007de9fd:
>> [0xffffffff812c6115, 0xffffffff812c6141): DW_OP_reg5 RDI
>> [0xffffffff812c6141, 0xffffffff812c6323): DW_OP_reg14 R14
>> [0xffffffff812c6323, 0xffffffff812c63fe): DW_OP_GNU_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value
>> [0xffffffff812c63fe, 0xffffffff812c6405): DW_OP_reg14 R14
>> [0xffffffff812c6405, 0xffffffff812c640a): DW_OP_GNU_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value)
>> DW_AT_name ("event")
>> DW_AT_decl_file ("/rw/compile/kernel/events/core.c")
>> DW_AT_decl_line (4641)
>> DW_AT_type (0x0333aac2 "perf_event *")
>> 0x0334c05e: DW_TAG_formal_parameter
>> DW_AT_location (0x007dea82:
>> [0xffffffff812c6137, 0xffffffff812c63f2): DW_OP_reg12 R12
>> [0xffffffff812c63f2, 0xffffffff812c63fe): DW_OP_GNU_entry_value(DW_OP_reg4 RSI), DW_OP_stack_value
>> [0xffffffff812c63fe, 0xffffffff812c640a): DW_OP_reg12 R12)
>> DW_AT_name ("group")
>> DW_AT_decl_file ("/rw/compile/kernel/events/core.c")
>> DW_AT_decl_line (4641)
>> DW_AT_type (0x03327059 "bool")
> hi,
> I don't see that on gcc compiled kernel, is that related to clang?
Yes, the case I tried to fix is from clang compiled kernel.
>
>
> <1><318d475>: Abbrev Number: 74 (DW_TAG_subprogram)
> <318d476> DW_AT_name : (indirect string, offset: 0xf5776): perf_event_read
> <318d47a> DW_AT_decl_file : 1
> <318d47a> DW_AT_decl_line : 4746
> <318d47c> DW_AT_decl_column : 12
> <318d47d> DW_AT_prototyped : 1
> <318d47d> DW_AT_type : <0x3135e35>
> <318d481> DW_AT_low_pc : 0xffffffff8135be90
> <318d489> DW_AT_high_pc : 0x196
> <318d491> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
> <318d493> DW_AT_call_all_calls: 1
> <318d493> DW_AT_sibling : <0x318d900>
> <2><318d497>: Abbrev Number: 30 (DW_TAG_formal_parameter)
> <318d498> DW_AT_name : (indirect string, offset: 0x491590): event
> <318d49c> DW_AT_decl_file : 1
> <318d49c> DW_AT_decl_line : 4746
> <318d49e> DW_AT_decl_column : 47
> <318d49f> DW_AT_type : <0x313a680>
> <318d4a3> DW_AT_location : 0x70c118 (location list)
> <318d4a7> DW_AT_GNU_locviews: 0x70c110
> <2><318d4ab>: Abbrev Number: 30 (DW_TAG_formal_parameter)
> <318d4ac> DW_AT_name : (indirect string, offset: 0x51a865): group
> <318d4b0> DW_AT_decl_file : 1
> <318d4b0> DW_AT_decl_line : 4746
> <318d4b2> DW_AT_decl_column : 59
> <318d4b3> DW_AT_type : <0x3136055>
> <318d4b7> DW_AT_location : 0x70c144 (location list)
> <318d4bb> DW_AT_GNU_locviews: 0x70c13e
>
> locations:
> 0070c144 ffffffff8135be90 (base address)
> 0070c14d v000000000000000 v000000000000000 views at 0070c13e for:
> ffffffff8135be90 ffffffff8135bed2 (DW_OP_reg4 (rsi))
> 0070c152 v000000000000000 v000000000000000 views at 0070c140 for:
> ffffffff8135bed2 ffffffff8135bf17 (DW_OP_reg14 (r14))
> 0070c158 v000000000000000 v000000000000000 views at 0070c142 for:
> ffffffff8135bf17 ffffffff8135c026 (DW_OP_entry_value: (DW_OP_reg4 (rsi)); DW_OP_stack_value)
> 0070c162 <End of list>
>
>
> other than that lgtm and I like the change Eduard suggested
>
> thanks,
> jirka
>
[...]
next prev parent reply other threads:[~2024-11-11 18:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 18:05 [PATCH dwarves 0/3] Check DW_OP_[GNU_]entry_value for possible parameter matching Yonghong Song
2024-11-08 18:05 ` [PATCH dwarves 1/3] dwarf_loader: Refactor function parameter__new() Yonghong Song
2024-11-11 11:26 ` Alan Maguire
2024-11-08 18:05 ` [PATCH dwarves 2/3] dwarf_loader: Refactor function check_dwarf_locations() Yonghong Song
2024-11-08 18:05 ` [PATCH dwarves 3/3] dwarf_loader: Check DW_OP_[GNU_]entry_value for possible parameter matching Yonghong Song
2024-11-10 11:38 ` Eduard Zingerman
2024-11-11 8:01 ` Eduard Zingerman
2024-11-11 12:36 ` Jiri Olsa
2024-11-11 13:42 ` Arnaldo Carvalho de Melo
2024-11-15 16:26 ` elfutils thread-safety (Was: [PATCH dwarves 3/3] dwarf_loader: Check DW_OP_[GNU_]entry_value for possible parameter matching) Mark Wielaard
2024-11-11 18:51 ` [PATCH dwarves 3/3] dwarf_loader: Check DW_OP_[GNU_]entry_value for possible parameter matching Yonghong Song
2024-11-11 9:54 ` Jiri Olsa
2024-11-11 18:54 ` Yonghong Song [this message]
2024-11-11 15:39 ` Alan Maguire
2024-11-12 1:51 ` Yonghong Song
2024-11-12 16:56 ` Alan Maguire
2024-11-12 17:07 ` Yonghong Song
2024-11-12 18:33 ` Alan Maguire
2024-11-12 18:51 ` Yonghong Song
2024-11-12 19:10 ` Arnaldo Carvalho de Melo
2024-11-13 17:33 ` Alan Maguire
2024-11-13 18:27 ` Yonghong Song
2024-11-14 12:16 ` Alan Maguire
2024-11-14 16:29 ` Yonghong Song
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=b8aab7b4-c85f-40d3-bffb-44ab91b33abd@linux.dev \
--to=yonghong.song@linux.dev \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=arnaldo.melo@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dwarves@vger.kernel.org \
--cc=kernel-team@fb.com \
--cc=olsajiri@gmail.com \
--cc=song@kernel.org \
/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).