From: Yonghong Song <yonghong.song@linux.dev>
To: Alan Maguire <alan.maguire@oracle.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: 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: Thu, 14 Nov 2024 08:29:09 -0800 [thread overview]
Message-ID: <5b777915-ef7f-4d21-8b23-cc79016aef32@linux.dev> (raw)
In-Reply-To: <9bfe242b-b09b-47a5-9446-1cfc0897aef2@oracle.com>
On 11/14/24 4:16 AM, Alan Maguire wrote:
> On 13/11/2024 18:27, Yonghong Song wrote:
>>> Thanks for the additional info! From Eduard's analysis, it seems like it
>>> is safer to take the libdw__lock around dwarf_getlocation(s), since
>>> multiple threads can access the CU location cache. I've tried tweaking
>>> Eduard's modification of Yonghong's original patch and adding a second
>>> patch to add locking; with these two patches applied
>>>
>>> - we see the desired behaviour where perf_event_read() is present in
>>> BTF; and
>>> - we don't see any segmentation faults after ~700 iterations where I saw
>>> one every 200 or so before
>>>
>>> Yonghong, Eduard - do these changes look okay from your side? Feel free
>>> to resubmit if so (fixing up attributions as you see fit if they look
>>> wrong of course). Thanks!
>> Thanks Alan for working on this. The following are some suggestions for
>> patch one:
>> 1. rename __dwarf_getlocations() to __parameter__locations()?
>> 2. rename param_reg_at_entry to parameter__locations()?
> Since it returns the register number, what about
> __parameter_reg/parameter_reg()?
>
>> 3. You missed the following:
>> static int param_reg_at_entry(Dwarf_Attribute *attr, int expected_reg)
>> {
>> ...
>> if (first_expr) // this line
>> return first_expr->atom; // this line
>> return -1;
>> }
>>
> I _think_ I've preserved the behaviour described by the comment at the
> start without using the first_expr code. Note that we set "ret" in the
> "case DW_OP_reg0 ... DW_OP_reg31:" clause of the switch statement, so
> will return that value; either directly, if the register number matches
> expected reg, or eventually if we don't find any DW_OP_*entry_value
> location info to return. This I think matches the described behaviour:
>
> /* For DW_AT_location 'attr':
> * - if first location is DW_OP_regXX with expected number, returns the
> register;
> * - if location DW_OP_entry_value(DW_OP_regXX) is in the list, returns
> the register;
> * - if first location is DW_OP_regXX, returns the register;
> * - otherwise returns -1.
> */
>
> ...but again I may have missed something here.
I have some comments in v2 and will reply there.
>
>> Patch 2 needs adjustment as well due to the above point #3.
>> Otherwise, LGTM. Since you are already preparing the patch,
>> please go ahead to pose v2 after you fixing the above things.
>>
> Sure; if the above sounds okay, I'll submit the patches with updates.
> After testing over 2000 iterations of pahole, I haven't seen a
> segmentation fault so I _think_ the locking in patch 2 is sufficient to
> avoid crashes.
>
> Thanks!
>
> Alan
>
>>> Alan
prev parent reply other threads:[~2024-11-14 16:29 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
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 [this message]
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=5b777915-ef7f-4d21-8b23-cc79016aef32@linux.dev \
--to=yonghong.song@linux.dev \
--cc=acme@kernel.org \
--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=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