On 22/08/2024 08:08, Krzysztof Kozlowski wrote:
> On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote:
>> On 21/08/2024 04:13, Tao Zhang wrote:
>>> The is some "magic" hard coded filtering in the replicators,
>>> which only passes through trace from a particular "source". Add
>>> a new property "filter-src" to label a phandle to the coresight
>>> trace source device matching the hard coded filtering for the port.
>>
>> Minor nit: Please do not use abbreviate "source" in the bindings.
>> I am not an expert on other changes below and will leave it to
>> Rob/Krzysztof to comment.
>>
>> Rob, Krzysztof,
>>
>> We need someway to "link" (add a phandle) from a "port". The patch below
>> is extending "standard" port to add a phandle. Please let us know if
>> there is a better way.
>>
>> e.g.:
>>
>> filters = list of tuples of port, phandle. ?
>>
>> e.g.:
>>
>> filters = < 0, <&tpdm_video>,
>> 1, <&tpdm_mdss>
>> >
>>
>
> Current solution feels like band-aid - what if next time you need some
> second filter? Or "wall"? Or whatever? Next property?
>
> Isn't filter just one endpoint in the graph?
>
> A <--> filter <--> B
To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a
multi output ports).
For clearer example:
A0 <--> .. <--> ..\ p0 / --> Filtered for (A1) <--> B1
A1 <--> .. <--> .. - < L(filters> p1 - --> Filtered for (A2) <--> B2
A2 <--> .. <--> ../ p2 \ --> Unfiltered <--> B0
> Instead of
>
> A <----through-filter----> B?
The problem is we need to know the components in the path from A0 to X
through, (Not just A0 and L). And also we need to know "which port (p0
vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out of the
link "L".
So ideally, we need a way to tie p0 -> A1, p1 -> A2.
would we need something else in the future ? I don't know for sure.
People could design their own things ;-). But this was the first time
ever in the last 12yrs since we supported coresight in the kernel.
(there is always a first time).
Fundamentally, the "ports" cannot have additional properties today.
Not sure if there are other usecases (I don't see why). So, we have
to manually extend like above, which I think is not nice.
Happy to proceed with anything that seems acceptable for you folks.
Suzuki
>
> Best regards,
> Krzysztof
>
On 10/16/2024 10:51 AM, Namhyung Kim wrote:
> Hello,
>
> On Fri, Oct 11, 2024 at 11:17:10AM -0600, Steve Clevenger wrote:
>> Changes in V9:
>> - Removed V8 patch files 1/4 and 2/4.
>> - Modified set_sym_in_dict (trace-event-python.c) to add map_pgoff
>> in dictionary as-is without regard to MAPPING_IDENTITY. This patch
>> file is now patch 2/2.
>
> I think the previous version had Leo's Reviewed-by tag.
>
> Leo, can you confirm if it still holds?
>
> Thanks,
> Namhyung
It did. You can confirm there's no arm-cs-trace-python.py script change
from V8. Note the patch file numbering is different (since 2 patches
dropped). The trace-event-python.c patch file changed so I had to drop
out his "Reviewed-by" tag for that file. Due to the patch numbering
change, I didn't want to add confusion so I left it out.
Steve
>
>>
>> Changes in V8:
>> - in arm-cs-trace-disasm.py, ensure map_pgoff is not converted to
>> string.
>> - Remove map_pgoff integer conversion in dso not found print
>> message.
>>
>> Changes in V7:
>> - In arm-cs-trace-disasm.py, fix print message core dump resulting
>> from mixed type arithmetic.
>> - Modify CS_ETM_TRACE_ON filter to filter zero start_addr. The
>> CS_ETM_TRACE_ON message is changed to print only in verbose mode.
>> - Removed verbose mode only notification for start_addr/stop_addr
>> outside of dso address range.
>>
>> Changes in V6:
>> - In arm-cs-trace-disasm.py, zero map_pgoff for kernel files. Add
>> map_pgoff to start/end address for dso not found message.
>> - Added "Reviewed-by" trailer for patches 1-3 previously reviewed
>> by Leo Yan in V4 and V5.
>>
>> Changes in V5:
>> - In symbol-elf.c, branch to exit_close label if open file.
>> - In trace_event_python.c, correct indentation. set_sym_in_dict
>> call parameter "map_pgoff" renamed as "addr_map_pgoff" to
>> match local naming.
>>
>> Changes in V4:
>> - In trace-event-python.c, fixed perf-tools-next merge problem.
>>
>> Changes in V3:
>> - Rebased to linux-perf-tools branch.
>> - Squash symbol-elf.c and symbol.h into same commit.
>> - In map.c, merge dso__is_pie() call into existing if statement.
>> - In arm-cs-trace-disasm.py, remove debug artifacts.
>>
>> Changes in V2:
>> - In dso__is_pie() (symbol-elf.c), Decrease indentation, add null pointer
>> checks per Leo Yan review.
>> - Updated mailing list distribution.
>>
>> Steve Clevenger (2):
>> Add map_pgoff to python dictionary
>> Adjust objdump start/end address per map_pgoff parameter
>>
>> tools/perf/scripts/python/arm-cs-trace-disasm.py | 16 +++++++++++-----
>> .../util/scripting-engines/trace-event-python.c | 9 ++++++---
>> 2 files changed, 17 insertions(+), 8 deletions(-)
>>
>> --
>> 2.44.0
>>
Some HW has static trace id which cannot be changed via
software programming. For this case, configure the trace id
in device tree with "arm,static-trace-id = <xxx>", and
call coresight_trace_id_get_static_system_id with the trace id value
in device probe function. The id will be reserved for the HW
all the time if the device is probed.
Changes since V3:
1. Adda new API function
int coresight_trace_id_get_system_static_id(int trace_id).
2. Use the term "static trace id" for these devices where
the hardware sets a non-programmable trace ID.
Changes since V2:
1. Change "trace-id" to "arm,trace-id".
2. Add trace id flag for getting preferred id or ODD id.
Changes since V1:
1. Add argument to coresight_trace_id_get_system_id for preferred id
instead of adding new function coresight_trace_id_reserve_system_id.
2. Add constraint to trace-id in dt-binding file.
Mao Jinlong (3):
dt-bindings: arm: Add arm,trace-id for coresight dummy source
coresight: Add support to get static id for system trace sources
coresight: dummy: Add static trace id support for dummy source
.../sysfs-bus-coresight-devices-dummy-source | 15 +++++
.../arm/arm,coresight-dummy-source.yaml | 6 ++
drivers/hwtracing/coresight/coresight-dummy.c | 59 +++++++++++++++++--
.../hwtracing/coresight/coresight-platform.c | 26 ++++++++
.../hwtracing/coresight/coresight-trace-id.c | 38 ++++++++----
.../hwtracing/coresight/coresight-trace-id.h | 9 +++
include/linux/coresight.h | 1 +
7 files changed, 140 insertions(+), 14 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source
--
2.41.0
Changes in V9:
- Removed V8 patch files 1/4 and 2/4.
- Modified set_sym_in_dict (trace-event-python.c) to add map_pgoff
in dictionary as-is without regard to MAPPING_IDENTITY. This patch
file is now patch 2/2.
Changes in V8:
- in arm-cs-trace-disasm.py, ensure map_pgoff is not converted to
string.
- Remove map_pgoff integer conversion in dso not found print
message.
Changes in V7:
- In arm-cs-trace-disasm.py, fix print message core dump resulting
from mixed type arithmetic.
- Modify CS_ETM_TRACE_ON filter to filter zero start_addr. The
CS_ETM_TRACE_ON message is changed to print only in verbose mode.
- Removed verbose mode only notification for start_addr/stop_addr
outside of dso address range.
Changes in V6:
- In arm-cs-trace-disasm.py, zero map_pgoff for kernel files. Add
map_pgoff to start/end address for dso not found message.
- Added "Reviewed-by" trailer for patches 1-3 previously reviewed
by Leo Yan in V4 and V5.
Changes in V5:
- In symbol-elf.c, branch to exit_close label if open file.
- In trace_event_python.c, correct indentation. set_sym_in_dict
call parameter "map_pgoff" renamed as "addr_map_pgoff" to
match local naming.
Changes in V4:
- In trace-event-python.c, fixed perf-tools-next merge problem.
Changes in V3:
- Rebased to linux-perf-tools branch.
- Squash symbol-elf.c and symbol.h into same commit.
- In map.c, merge dso__is_pie() call into existing if statement.
- In arm-cs-trace-disasm.py, remove debug artifacts.
Changes in V2:
- In dso__is_pie() (symbol-elf.c), Decrease indentation, add null pointer
checks per Leo Yan review.
- Updated mailing list distribution.
Steve Clevenger (2):
Add map_pgoff to python dictionary
Adjust objdump start/end address per map_pgoff parameter
tools/perf/scripts/python/arm-cs-trace-disasm.py | 16 +++++++++++-----
.../util/scripting-engines/trace-event-python.c | 9 ++++++---
2 files changed, 17 insertions(+), 8 deletions(-)
--
2.44.0
On 10/9/2024 2:13 PM, Leo Yan wrote:
> On 9/9/2024 10:30 PM, Steve Clevenger wrote:
>>
>> Add dso__is_pie global to read the .dynamic section DT_FLAGS_1 entry for
>> the DF_1_PIE flag. This identifies position executable code.
>>
>> Signed-off-by: Steve Clevenger <scclevenger(a)os.amperecomputing.com>
>> Reviewed-by: Leo Yan <leo.yan(a)arm.com>
>> ---
>> tools/perf/util/symbol-elf.c | 61 ++++++++++++++++++++++++++++++++++++
>> tools/perf/util/symbol.h | 1 +
>> 2 files changed, 62 insertions(+)
>>
>> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
>> index e398abfd13a0..babe47976922 100644
>> --- a/tools/perf/util/symbol-elf.c
>> +++ b/tools/perf/util/symbol-elf.c
>> @@ -662,6 +662,67 @@ static int dso__synthesize_plt_got_symbols(struct dso *dso, Elf *elf,
>> return err;
>> }
>>
>> +/*
>> + * Check dynamic section DT_FLAGS_1 for a Position Independent
>> + * Executable (PIE).
>> + */
>> +bool dso__is_pie(struct dso *dso)
>> +{
>> + Elf *elf = NULL;
>> + Elf_Scn *scn = NULL;
>> + GElf_Ehdr ehdr;
>> + GElf_Shdr shdr;
>> + bool is_pie = false;
>> + char dso_path[PATH_MAX];
>> + int fd = -1;
>> +
>> + if (!dso || (elf_version(EV_CURRENT) == EV_NONE))
>> + goto exit; // false
>> +
>> + dso__build_id_filename(dso, dso_path, sizeof(dso_path), false);
>> +
>> + fd = open(dso_path, O_RDONLY);
>> +
>> + if (fd < 0) {
>> + pr_debug("%s: cannot read cached %s.\n", __func__, dso_path);
>> + goto exit; // false
>> + }
>> +
>> + elf = elf_begin(fd, ELF_C_READ, NULL);
>> + gelf_getehdr(elf, &ehdr);
>> +
>> + if (ehdr.e_type == ET_DYN) {
>> + Elf_Data *data;
>> + GElf_Dyn *entry;
>> + int n_entries = shdr.sh_size / sizeof(GElf_Dyn);
>
> I took time to play this series on Arm64 machine and found issue in above
> sentence. As the 'shdr' strucutre is read out from elf_section_by_name()
> below, but it calculates the entries before reading out the section header.
> Therefore, I observed that program will not be detected as PIE executable due
> to 'n_entries' is 0.
>
> With fixing this bug, then I observed the regression caused by patch 02.
>
> Below are steps:
>
> - Build test program with below command:
>
> # gcc -pie -Wl,-z,relro,-z,now -o test test.c
> # readelf readelf -a test | grep FLAGS
> 0x000000000000001e (FLAGS) BIND_NOW
> 0x000000006ffffffb (FLAGS_1) Flags: NOW PIE
>
> The test program is a simple infinite loop. I run this program in a docker
> container with Fedora 40.
>
> - Record trace data:
>
> # perf record -e cycles -p 149531
> # perf script
>
> test 149531 483168.078485: 4986 cycles: aaaacde401b4
> [unknown] (/home/test)
> test 149531 483168.078564: 134207 cycles: aaaacde401b4
> [unknown] (/home/test)
> test 149531 483168.079305: 1257097 cycles: aaaacde401b4
> [unknown] (/home/test)
>
> You can see it fails to parse symbol and print out [unknown].
>
> After I reverted patch 02 in this series, then:
>
> # perf script
> test 149531 483168.078485: 4986 cycles: aaaacde401b4
> main+0xc (/home/test)
> test 149531 483168.078564: 134207 cycles: aaaacde401b4
> main+0xc (/home/test)
> test 149531 483168.079305: 1257097 cycles: aaaacde401b4
> main+0xc (/home/test)
>
> Not sure if I miss anything for PIE executable, seems to me, we should drop
> the first two patches and just pass pg_off to python script?
> > Thanks,
> Leo
Hi Leo,
I verified the perf/arm-cs-trace-disasm.py script patch results for
CoreSight user and kernel trace using Fedora distros 37 and higher. I
did little to test non-CoreSight trace, but I do see the dso__is_pie
initialization error, and the problem revealed by your test program. As
a side effect, the problem would contribute to the CoreSight user
instruction test passes.
The arm-cs-trace-disasm.py python script has a legacy IF block to force
'dso_vm_start' to zero for kernel code. Similarly, map_pgoff gets forced
to zero here. See the adjacent comment pertaining to memory offsets for
kernel dso and executable file dso. This, I think, is the root of the
misunderstanding with regard to the PIE check. I see the python IF
comparison includes a check for dso_start == 0x400000 but I see no
information as to why this hardcoded value is relevant. Do you know?
perf has (or now has) the information (e.g. map__rip_2objdump,
map__objdump_2mem) needed to make all objdump address adjustments prior
to calling the script. The script could even be made redundant as
suggested in an earlier thread. In the meantime, Ampere needs this
working so the patch implementation has to work with the current
perf/script implementation.
I agree the revised approach is to pass pgoff to the updated script
unmodified.This means patch 3 will pass map_pgoff unmodified by
MAPPING_TYPE into the dictionary. Patch 1-2 goes away, and patch 4
remains as-is.
Steve
>
>> +
>> + scn = elf_section_by_name(elf, &ehdr, &shdr, ".dynamic", NULL);
>> + if (!scn)
>> + goto exit_close; // false
>> +
>> + data = (Elf_Data *) elf_getdata(scn, NULL);
>> + if (!data || !data->d_buf)
>> + goto exit_close; // false
>> +
>> + // check DT_FLAGS_1
>> + for (int i = 0; i < n_entries; i++) {
>> + entry = ((GElf_Dyn *) data->d_buf) + i;
>> + if (entry->d_tag == DT_FLAGS_1) {
>> + if ((entry->d_un.d_val & DF_1_PIE) != 0) {
>> + is_pie = true;
>> + break;
>> + }
>> + }
>> + } // end for
>> + }
>> +
>> +exit_close:
>> + elf_end(elf);
>> + close(fd);
>> +exit:
>> + return is_pie;
>> +}
>> +
>> /*
>> * We need to check if we have a .dynsym, so that we can handle the
>> * .plt, synthesizing its symbols, that aren't on the symtabs (be it
>> diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
>> index 3fb5d146d9b1..33ea2596ce31 100644
>> --- a/tools/perf/util/symbol.h
>> +++ b/tools/perf/util/symbol.h
>> @@ -127,6 +127,7 @@ void dso__insert_symbol(struct dso *dso,
>> struct symbol *sym);
>> void dso__delete_symbol(struct dso *dso,
>> struct symbol *sym);
>> +bool dso__is_pie(struct dso *dso);
>>
>> struct symbol *dso__find_symbol(struct dso *dso, u64 addr);
>> struct symbol *dso__find_symbol_nocache(struct dso *dso, u64 addr);
>> --
>> 2.44.0
>>
Some HW has static trace id which cannot be changed via
software programming. For this case, configure the trace id
in device tree with "arm,static-trace-id = <xxx>", and
call coresight_trace_id_get_static_system_id with the trace id value
in device probe function. The id will be reserved for the HW
all the time if the device is probed.
Changes since V3:
1. Adda new API function
int coresight_trace_id_get_system_static_id(int trace_id).
2. Use the term "static trace id" for these devices where
the hardware sets a non-programmable trace ID.
Changes since V2:
1. Change "trace-id" to "arm,trace-id".
2. Add trace id flag for getting preferred id or ODD id.
Changes since V1:
1. Add argument to coresight_trace_id_get_system_id for preferred id
instead of adding new function coresight_trace_id_reserve_system_id.
2. Add constraint to trace-id in dt-binding file.
Mao Jinlong (3):
dt-bindings: arm: Add arm,trace-id for coresight dummy source
coresight: Add support to get static id for system trace sources
coresight: dummy: Add static trace id support for dummy source
.../sysfs-bus-coresight-devices-dummy-source | 15 +++++
.../arm/arm,coresight-dummy-source.yaml | 6 ++
drivers/hwtracing/coresight/coresight-dummy.c | 59 +++++++++++++++++--
.../hwtracing/coresight/coresight-platform.c | 26 ++++++++
.../hwtracing/coresight/coresight-trace-id.c | 38 ++++++++----
.../hwtracing/coresight/coresight-trace-id.h | 9 +++
include/linux/coresight.h | 1 +
7 files changed, 140 insertions(+), 14 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source
--
2.46.0
On 09/10/2024 10:55, Jie Gan wrote:
> The Coresight TMC Control Unit(CTCU) device hosts miscellaneous configuration
> registers to control various features related to TMC ETR device.
>
Please rebase this on the v6.12-rc1, which has the sink specific trace
id allocation changes and drop the "Depends-on" tags on the patches
which don't make any sense at all.
Suzuki
On 09/10/2024 09:50, Songwei Chai wrote:
> The format of tpdm's peripheral id is 1f0exx. To avoid potential
> conflicts in the future, update the .id_table's id to 0x001f0e00.
> This update will narrow down the matching range and prevent incorrect
> matches. For example, another component's peripheral id might be
> f0e00, which would incorrectly match the old id.
>
> Signed-off-by: Songwei Chai <quic_songchai(a)quicinc.com>
> ---
> drivers/hwtracing/coresight/coresight-tpdm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index b7d99e91ab84..8e2985d17549 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -1308,8 +1308,8 @@ static void tpdm_remove(struct amba_device *adev)
> */
> static struct amba_id tpdm_ids[] = {
> {
> - .id = 0x000f0e00,
> - .mask = 0x000fff00,
> + .id = 0x001f0e00,
> + .mask = 0x00ffff00,
> },
> { 0, 0, NULL },
> };
>
Please could you add "Fixes" tag for this ? You don't want an old kernel
detect something else as TPDM, so this must go to stable kernels.
Also, while at it, please could you intend the id and mask values with
tabs, so it is easier to what exactly we are matching ? e.g,
.id = 0x001f0e00,
.mask = 0x00ffff00,
Kind regards
Suzuki
On 10/8/2024 2:00 PM, Namhyung Kim wrote:
> On Tue, Oct 08, 2024 at 11:24:45AM -0700, Steve Clevenger wrote:
>>
>> Hello Namhyung,
>>
>> Sorry your question is so late. I don't include the ELF headers here,
>> but the problem can be seen with a perf.data packet dump of user
>> instruction trace capture. The problem is with the non-zero pgoff. The
>> arm-cs-trace-disasm.py script was never passed pgoff information to
>> adjust the start/end disassemble range passed to objdump. This patch
>> distributes the fix between perf and the arm-cs-trace-disasm.py script.
>>
>> Here's a brief excerpt from an e-mail I sent to James Clark describing
>> the patch before I submitted it.
>
> Oh, is it applied to the coresight tree already? I don't think I got
> any notification for that. Please make sure to notify perf maintainers
> (and hopefullly to get Ack's) when you touch non-coresight part of the
> code.
>
> Also I think we need to clarify how to route coresight tool patches. I
> thought they are going through the perf-tools tree. But it doesn't seem
> to be the case?
>
> Anyway, sorry about being late on this.
FYI. These patch(es) were based on perf-tools-next at revision
6.11.0-rc3. All ack'd by Leo Yan. If they could get merged to
perf-tools, that would be great!
>
>>
>> -----------------------------------------------------------------
>> .
>> .
>> This e-mail is to document what I know and don’t know about the problem.
>> The background is Fedora 38 introduced non-zero text offsets into common
>> shared objects and executables (e.g. libc.so.6, etc.).
>>
>> If you were to ‘perf report --dump’ the perf.data of a user mode
>> instruction trace on Fedora 37 and grep the PERF_RECORD_MMAP2 packets
>> you’ll notice all zero values (@ 0) for shared binary and executable
>> text offsets. Repeat the same for user trace collected on Fedora 38/39,
>> and these text offsets show as non-zero.
>>
>> Fedora 37:
>>
>> 4294967295 18446744073709551615 0x8ac8 [0x78]: PERF_RECORD_MMAP2
>> 2389577/2389577: [0xffff85124000(0x42000) @ 0 103:04 805306555
>> 1941233998]: r-xp /usr/lib/ld-linux-aarch64.so.1
>> 4294967295 18446744073709551615 0x8b40 [0x60]: PERF_RECORD_MMAP2
>> 2389577/2389577: [0xffff85161000(0x1000) @ 0 00:00 0 0]: r-xp [vdso]
>> 4294967295 18446744073709551615 0x8ba0 [0x68]: PERF_RECORD_MMAP2
>> 2389577/2389577: [0xaaaab09b0000(0x10000) @ 0 103:04 1140851919
>> 994218038]: r-xp /usr/bin/dd
>> 4294967295 18446744073709551615 0x8c08 [0x70]: PERF_RECORD_MMAP2
>> 2389577/2389577: [0xffff84f70000(0x1a9000) @ 0 103:04 1677721733
>> 3891973508]: r-xp /usr/lib64/libc.so.6
>>
>> Fedora 39:
>>
>> 4294967295 18446744073709551615 0x8ac8 [0x78]: PERF_RECORD_MMAP2
>> 18229/18229: [0xffffa5512000(0x1d000) @ 0x10000 103:04 161 4093340249]:
>> r-xp /usr/lib/ld-linux-aarch64.so.1
>> 4294967295 18446744073709551615 0x8b40 [0x60]: PERF_RECORD_MMAP2
>> 18229/18229: [0xffffa554f000(0x1000) @ 0 00:00 0 0]: r-xp [vdso]
>> 4294967295 18446744073709551615 0x8ba0 [0x68]: PERF_RECORD_MMAP2
>> 18229/18229: [0xaaaade7e0000(0xb000) @ 0x10000 103:04 536876423
>> 421616320]: r-xp /usr/bin/dd
>> 4294967295 18446744073709551615 0x8c08 [0x70]: PERF_RECORD_MMAP2
>> 18229/18229: [0xffffa5360000(0x11f000) @ 0x30000 103:04 536873199
>> 2415801053]: r-xp /usr/lib64/libc.so.6
>>
>> The arm-cs-trace-disasm.py script never gets to see the text offset into
>> the dso binaries, so has no opportunity to adjust the start/end address
>> range passed to objdump. This wasn’t a problem on Fedora 37 and below
>> since there’s no start/end adjustment for a zero text offset. On Fedora
>> 38/39 distros, the instruction trace shows unconditional branch
>> instructions which do not branch to the target address, the clearest
>> indication of trouble.
>
> Ok, thanks for sharing this. I'm ok with exposing pgoff to the python
> script itself. But I'd like to make sure if it works correctly with
> PIEs that have non-zero page offsets in other places (probably ok).
>
> Thanks,
> Namhyung
>
>
>> -----------------------------------------------------------------
>>
>> On 10/7/2024 10:51 PM, Namhyung Kim wrote:
>>> Hello,
>>>
>>> Sorry for the long delay. But can you please explain your problem in
>>> more detail? Showing ELF program (or section) header would be helpful
>>> as well.
>>>
>>> Is the problem when the text mapping has non-zero pgoff only? Is the
>>> kernel symbols working correctly? Or is it just the Python script
>>> broken?
>>>
>>> Thanks,
>>> Namhyung
>>>
>>> On Mon, Sep 09, 2024 at 03:30:02PM -0600, Steve Clevenger wrote:
>>>> Changes in V8:
>>>> - in arm-cs-trace-disasm.py, ensure map_pgoff is not converted to
>>>> string.
>>>> - Remove map_pgoff integer conversion in dso not found print
>>>> message.
>>>>
>>>> Changes in V7:
>>>> - In arm-cs-trace-disasm.py, fix print message core dump resulting
>>>> from mixed type arithmetic.
>>>> - Modify CS_ETM_TRACE_ON filter to filter zero start_addr. The
>>>> CS_ETM_TRACE_ON message is changed to print only in verbose mode.
>>>> - Removed verbose mode only notification for start_addr/stop_addr
>>>> outside of dso address range.
>>>>
>>>> Changes in V6:
>>>> - In arm-cs-trace-disasm.py, zero map_pgoff for kernel files. Add
>>>> map_pgoff to start/end address for dso not found message.
>>>> - Added "Reviewed-by" trailer for patches 1-3 previously reviewed
>>>> by Leo Yan in V4 and V5.
>>>>
>>>> Changes in V5:
>>>> - In symbol-elf.c, branch to exit_close label if open file.
>>>> - In trace_event_python.c, correct indentation. set_sym_in_dict
>>>> call parameter "map_pgoff" renamed as "addr_map_pgoff" to
>>>> match local naming.
>>>>
>>>> Changes in V4:
>>>> - In trace-event-python.c, fixed perf-tools-next merge problem.
>>>>
>>>> Changes in V3:
>>>> - Rebased to linux-perf-tools branch.
>>>> - Squash symbol-elf.c and symbol.h into same commit.
>>>> - In map.c, merge dso__is_pie() call into existing if statement.
>>>> - In arm-cs-trace-disasm.py, remove debug artifacts.
>>>>
>>>> Changes in V2:
>>>> - In dso__is_pie() (symbol-elf.c), Decrease indentation, add null pointer
>>>> checks per Leo Yan review.
>>>> - Updated mailing list distribution.
>>>>
>>>> Steve Clevenger (4):
>>>> Add dso__is_pie call to identify ELF PIE
>>>> Force MAPPING_TYPE__IDENTIY for PIE
>>>> Add map pgoff to python dictionary based on MAPPING_TYPE
>>>> Adjust objdump start/end range per map pgoff parameter
>>>>
>>>> .../scripts/python/arm-cs-trace-disasm.py | 17 ++++--
>>>> tools/perf/util/map.c | 4 +-
>>>> .../scripting-engines/trace-event-python.c | 13 +++-
>>>> tools/perf/util/symbol-elf.c | 61 +++++++++++++++++++
>>>> tools/perf/util/symbol.h | 1 +
>>>> 5 files changed, 86 insertions(+), 10 deletions(-)
>>>>
>>>> --
>>>> 2.44.0
>>>>
>>