[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a3ae638f-8efc-70d9-75fd-9473db3de24d@arm.com>
Date: Wed, 20 Dec 2023 12:06:59 +0000
From: James Clark <james.clark@....com>
To: Ruidong Tian <tianruidong@...ux.alibaba.com>, linux-kernel@...r.kernel.org
Cc: coresight@...ts.linaro.org, suzuki.poulose@....com,
mike.leach@...aro.org, alexander.shishkin@...ux.intel.com,
linux-arm-kernel@...ts.infradead.org, adrian.hunter@...el.com,
linux-perf-users@...r.kernel.org, leo.yan@...aro.org, al.grant@....com,
mathieu.poirier@...aro.org, tor@...com, acme@...hat.com
Subject: Re: [PATCH 2/3] perf scripts python: arm-cs-trace-disasm.py: set
start vm addr of exectable file to 0
On 14/12/2023 12:33, Ruidong Tian wrote:
> For exectable ELF file, which e_type is ET_EXEC, dso start address is a
> absolute address other than offset. Just set vm_start to zero when dso
> start is 0x400000, which means it is a exectable file.
>
> Signed-off-by: Ruidong Tian <tianruidong@...ux.alibaba.com>
> ---
> tools/perf/scripts/python/arm-cs-trace-disasm.py | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> index 46bf6b02eea1..c9e14af5b58c 100755
> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> @@ -260,8 +260,9 @@ def process_event(param_dict):
>
> if (options.objdump_name != None):
> # It doesn't need to decrease virtual memory offset for disassembly
> - # for kernel dso, so in this case we set vm_start to zero.
> - if (dso == "[kernel.kallsyms]"):
> + # for kernel dso and executable file dso, so in this case we set
> + # vm_start to zero.
> + if (dso == "[kernel.kallsyms]" or dso_start == 0x400000):
> dso_vm_start = 0
> else:
> dso_vm_start = int(dso_start)
I confirmed that this fixes the disassembly for static binaries. It
would have been nice to check the type of the file rather than using a
magic number, but it's not that easy and I don't really see a chance of
the number having a false positive.
I wonder if it's worth putting a fixes tag on this one? For the other
ones I'd say no tag as they have a chance of breaking things.
Reviewed-by: James Clark <james.clark@....com>
Powered by blists - more mailing lists