From: Leo Yan <leo.yan@arm.com>
To: scclevenger@os.amperecomputing.com, james.clark@linaro.org,
mike.leach@linaro.org
Cc: ilkka@os.amperecomputing.com, coresight@lists.linaro.org,
linux-perf-users@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V7 4/4] Adjust objdump start/end range per map pgoff parameter
Date: Mon, 9 Sep 2024 21:33:27 +0100 [thread overview]
Message-ID: <fc2870a0-3e0e-464c-b468-70c5ee4a6ebb@arm.com> (raw)
In-Reply-To: <22539ca0-551d-4cfc-94f9-4a291998a363@os.amperecomputing.com>
On 9/7/2024 12:20 AM, Steve Clevenger wrote:
[...]
>>>> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/
>>>> perf/scripts/python/arm-cs-trace-disasm.py
>>>> index 7aff02d84ffb..a867e0db02b8 100755
>>>> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
>>>> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
>>>> @@ -187,6 +187,7 @@ def process_event(param_dict):
>>>> dso_start = get_optional(param_dict, "dso_map_start")
>>>> dso_end = get_optional(param_dict, "dso_map_end")
>>>> symbol = get_optional(param_dict, "symbol")
>>>> + map_pgoff = get_optional(param_dict, "map_pgoff")
>>>
>>>
>>> I am concerned the two sentences below are inconsistence: one uses
>>> 'start_addr + map_pgoff' and the other uses 'start_addr + int(map_pgoff)'.
>>>
>>
>> Valid point. It's working fine as is, but how is it even working? I look
>> at print_disam/read_disasm, and no type conversion is done in either
>> call. The dso_start parameter for these calls is actually dso_vm_start
>> which is the dso_start integer conversion.
I agreed with you. After reading code, I have same conclusion that we don't
need to type conversion to int type.
> Python thinks the map_pgoff object is already an integer. For example,
> map_pgoff = get_optional(param_dict, "map_pgoff")
> print("%d" % map_pgoff.isdigit())
>
> AttributeError: 'int' object has no attribute 'isdigit'
> Fatal Python error: handler_call die: problem in Python trace event handler
>
> Converting map_pgoff to a string works in the print statement.
>
> print("%d" % str(map_pgoff).isdigit())
> 1
>
> I'm not sure, but it's possible get_optional() during some call had
> converted it to '[unknown]' which would cause a problem.
>
> I can explicitly force to integer.
For backward compatibility, we can use below code:
map_pgoff = get_optional(param_dict, "map_pgoff")
if (map_pgoff == '[unknown]'):
map_pgoff = 0
Then in the later flow, we should can always use "map_pgoff" as an int type.
I struggled for James reported issue.
The variables “map_pgoff,” “dso_start,” and “dso_end” are set together in the
Python engine. All of them should be of type int if the DSO is found, or all
should be ‘[unknown]’ if the DSO is missing. We have checked the types for
“dso_start” and “dso_end”, and if either is ‘[unknown]’ the flow will directly
bail out. Thus, in theory, “map_pgoff” will not cause trouble if it is an
‘[unknown]’ string.
One possibility is that James has applied your patches but has not built perf.
So, the field “map_pgoff” is not passed from the Python engine, which will
cause the reported error. I think the proposed above change can effectively
avoid the error.
Thanks,
Leo
next prev parent reply other threads:[~2024-09-09 20:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 22:28 [PATCH V7 0/4] arm-cs-trace-disasm.py/perf must accommodate non-zero DSO text offset Steve Clevenger
2024-09-05 22:28 ` [PATCH V7 4/4] Adjust objdump start/end range per map pgoff parameter Steve Clevenger
2024-09-06 11:27 ` Leo Yan
2024-09-06 17:27 ` Steve Clevenger
2024-09-06 23:20 ` Steve Clevenger
2024-09-09 20:33 ` Leo Yan [this message]
2024-09-09 20:56 ` Steve Clevenger
2024-09-05 22:28 ` [PATCH V7 3/4] Add map pgoff to python dictionary based on MAPPING_TYPE Steve Clevenger
2024-09-05 22:28 ` [PATCH V7 2/4] Force MAPPING_TYPE__IDENTIY for PIE Steve Clevenger
2024-09-05 22:28 ` [PATCH V7 1/4] Add dso__is_pie call to identify ELF PIE Steve Clevenger
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=fc2870a0-3e0e-464c-b468-70c5ee4a6ebb@arm.com \
--to=leo.yan@arm.com \
--cc=coresight@lists.linaro.org \
--cc=ilkka@os.amperecomputing.com \
--cc=james.clark@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mike.leach@linaro.org \
--cc=scclevenger@os.amperecomputing.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).