CoreSight

coresight@lists.linaro.org

7 participants
2453 discussions

Re: [PATCH] perf scripts python arm-cs-trace-disasm.py: Skip disasm if address continuity is broken

by James Clark

On 05/08/2024 1:22 pm, Ganapatrao Kulkarni wrote: > > > On 01-08-2024 03:30 pm, James Clark wrote: >> >> >> On 24/07/2024 3:45 pm, James Clark wrote: >>> >>> >>> On 24/07/2024 7:38 am, Ganapatrao Kulkarni wrote: >>>> >>>> >>>> On 23-07-2024 09:16 pm, James Clark wrote: >>>>> >>>>> >>>>> On 23/07/2024 4:26 pm, Ganapatrao Kulkarni wrote: >>>>>> >>>>>> >>>>>> On 23-07-2024 06:40 pm, James Clark wrote: >>>>>>> >>>>>>> >>>>>>> On 22/07/2024 11:02 am, Ganapatrao Kulkarni wrote: >>>>>>>> >>>>>>>> Hi James, >>>>>>>> >>>>>>>> On 19-07-2024 08:09 pm, James Clark wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 19/07/2024 10:26 am, Ganapatrao Kulkarni wrote: >>>>>>>>>> To generate the instruction tracing, script uses 2 contiguous >>>>>>>>>> packets >>>>>>>>>> address range. If there a continuity brake due to >>>>>>>>>> discontiguous branch >>>>>>>>>> address, it is required to reset the tracing and start tracing >>>>>>>>>> with the >>>>>>>>>> new set of contiguous packets. >>>>>>>>>> >>>>>>>>>> Adding change to identify the break and complete the remaining >>>>>>>>>> tracing >>>>>>>>>> of current packets and restart tracing from new set of >>>>>>>>>> packets, if >>>>>>>>>> continuity is established. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Ganapatrao, >>>>>>>>> >>>>>>>>> Can you add a before and after example of what's changed to the >>>>>>>>> commit message? It wasn't immediately obvious to me if this is >>>>>>>>> adding missing output, or it was correcting the tail end of the >>>>>>>>> output that was previously wrong. >>>>>>>> >>>>>>>> It is adding tail end of the trace as well avoiding the segfault >>>>>>>> of the perf application. With out this change the perf segfaults >>>>>>>> with as below log >>>>>>>> >>>>>>>> >>>>>>>> ./perf script >>>>>>>> --script=python:./scripts/python/arm-cs-trace-disasm.py -- -d >>>>>>>> objdump -k ../../vmlinux -v $* > dump >>>>>>>> objdump: error: the stop address should be after the start address >>>>>>>> Traceback (most recent call last): >>>>>>>> File "./scripts/python/arm-cs-trace-disasm.py", line 271, in >>>>>>>> process_event >>>>>>>> print_disam(dso_fname, dso_vm_start, start_addr, stop_addr) >>>>>>>> File "./scripts/python/arm-cs-trace-disasm.py", line 105, in >>>>>>>> print_disam >>>>>>>> for line in read_disam(dso_fname, dso_start, start_addr, >>>>>>>> stop_addr): >>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>> File "./scripts/python/arm-cs-trace-disasm.py", line 99, in >>>>>>>> read_disam >>>>>>>> disasm_output = >>>>>>>> check_output(disasm).decode('utf-8').split('\n') >>>>>>>> ^^^^^^^^^^^^^^^^^^^^ >>>>>>>> File "/usr/lib64/python3.12/subprocess.py", line 466, in >>>>>>>> check_output >>>>>>>> return run(*popenargs, stdout=PIPE, timeout=timeout, >>>>>>>> check=True, >>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>> File "/usr/lib64/python3.12/subprocess.py", line 571, in run >>>>>>>> raise CalledProcessError(retcode, process.args, >>>>>>>> subprocess.CalledProcessError: Command '['objdump', '-d', '-z', >>>>>>>> '--start-address=0xffff80008125b758', >>>>>>>> '--stop-address=0xffff80008125a934', '../../vmlinux']' returned >>>>>>>> non-zero exit status 1. >>>>>>>> Fatal Python error: handler_call_die: problem in Python trace >>>>>>>> event handler >>>>>>>> Python runtime state: initialized >>>>>>>> >>>>>>>> Current thread 0x0000ffffb05054e0 (most recent call first): >>>>>>>> <no Python frame> >>>>>>>> >>>>>>>> Extension modules: perf_trace_context, systemd._journal, >>>>>>>> systemd._reader, systemd.id128, report._py3report, >>>>>>>> _dbus_bindings, problem._py3abrt (total: 7) >>>>>>>> Aborted (core dumped) >>>>>>>> >>>>>>>>> >>>>>>>>>> Signed-off-by: Ganapatrao Kulkarni >>>>>>>>>> <gankulkarni(a)os.amperecomputing.com> >>>>>>>>>> --- >>>>>>>>>> tools/perf/scripts/python/arm-cs-trace-disasm.py | 10 >>>>>>>>>> ++++++++++ >>>>>>>>>> 1 file changed, 10 insertions(+) >>>>>>>>>> >>>>>>>>>> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>>>>>> b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>>>>>> index d973c2baed1c..ad10cee2c35e 100755 >>>>>>>>>> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>>>>>> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>>>>>> @@ -198,6 +198,10 @@ def process_event(param_dict): >>>>>>>>>> cpu_data[str(cpu) + 'addr'] = addr >>>>>>>>>> return >>>>>>>>>> + if (cpu_data.get(str(cpu) + 'ip') == None): >>>>>>>>>> + cpu_data[str(cpu) + 'ip'] = ip >>>>>>>>>> + >>>>>>>>> >>>>>>>>> Do you need to write into the global cpu_data here? Doesn't it >>>>>>>>> get overwritten after you load it back into 'prev_ip' >>>>>>>> >>>>>>>> No, the logic is same as holding the addr of previous packet. >>>>>>>> Saving the previous packet saved ip in to prev_ip before >>>>>>>> overwriting with the current packet. >>>>>>> >>>>>>> It's not exactly the same logic as holding the addr of the >>>>>>> previous sample. For addr, we return on the first None, with your >>>>>>> change we now "pretend" that the second one is also the previous >>>>>>> one: >>>>>>> >>>>>>> if (cpu_data.get(str(cpu) + 'addr') == None): >>>>>>> cpu_data[str(cpu) + 'addr'] = addr >>>>>>> return <----------------------------sample 0 return >>>>>>> >>>>>>> if (cpu_data.get(str(cpu) + 'ip') == None): >>>>>>> cpu_data[str(cpu) + 'ip'] = ip <---- sample 1 save but no >>>>>>> return >>>>>>> >>>>>>> Then for sample 1 'prev_ip' is actually now the 'current' IP: >>>>>> >>>>>> Yes, it is dummy for first packet. Added anticipating that we wont >>>>>> hit the discontinuity for the first packet itself. >>>>>> >>>>>> Can this be changed to more intuitive like below? >>>>>> >>>>>> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>> b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>> index d973c2baed1c..d49f5090059f 100755 >>>>>> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>> @@ -198,6 +198,8 @@ def process_event(param_dict): >>>>>> cpu_data[str(cpu) + 'addr'] = addr >>>>>> return >>>>>> >>>>>> + if (cpu_data.get(str(cpu) + 'ip') != None): >>>>>> + prev_ip = cpu_data[str(cpu) + 'ip'] >>>>>> >>>>>> if (options.verbose == True): >>>>>> print("Event type: %s" % name) >>>>>> @@ -243,12 +245,18 @@ def process_event(param_dict): >>>>>> >>>>>> # Record for previous sample packet >>>>>> cpu_data[str(cpu) + 'addr'] = addr >>>>>> + cpu_data[str(cpu) + 'ip'] = stop_addr >>>>>> >>>>>> # Handle CS_ETM_TRACE_ON packet if start_addr=0 and >>>>>> stop_addr=4 >>>>>> if (start_addr == 0 and stop_addr == 4): >>>>>> print("CPU%d: CS_ETM_TRACE_ON packet is inserted" >>>>>> % cpu) >>>>>> return >>>>>> >>>>>> + if (stop_addr < start_addr and prev_ip != 0): >>>>>> + # Continuity of the Packets broken, set start_addr >>>>>> to previous >>>>>> + # packet ip to complete the remaining tracing of >>>>>> the address range. >>>>>> + start_addr = prev_ip >>>>>> + >>>>>> if (start_addr < int(dso_start) or start_addr > >>>>>> int(dso_end)): >>>>>> print("Start address 0x%x is out of range [ 0x%x >>>>>> .. 0x%x ] for dso %s" % (start_addr, int(dso_start), int(dso_end), >>>>>> dso)) >>>>>> return >>>>>> >>>>>> Without this patch below is the failure log(with segfault) for >>>>>> reference. >>>>>> >>>>>> [root@sut01sys-r214 perf]# timeout 4s ./perf record -e cs_etm// -C >>>>>> 1 dd if=/dev/zero of=/dev/null >>>>>> [ perf record: Woken up 1 times to write data ] >>>>>> [ perf record: Captured and wrote 1.087 MB perf.data ] >>>>>> [root@sut01sys-r214 perf]# ./perf script >>>>>> --script=python:./scripts/python/arm-cs-trace-disasm.py -- -d >>>>>> objdump -k ../../vmlinux -v $* > dump >>>>>> objdump: error: the stop address should be after the start address >>>>>> Traceback (most recent call last): >>>>>> File "./scripts/python/arm-cs-trace-disasm.py", line 271, in >>>>>> process_event >>>>>> print_disam(dso_fname, dso_vm_start, start_addr, stop_addr) >>>>>> File "./scripts/python/arm-cs-trace-disasm.py", line 105, in >>>>>> print_disam >>>>>> for line in read_disam(dso_fname, dso_start, start_addr, >>>>>> stop_addr): >>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> File "./scripts/python/arm-cs-trace-disasm.py", line 99, in >>>>>> read_disam >>>>>> disasm_output = check_output(disasm).decode('utf-8').split('\n') >>>>>> ^^^^^^^^^^^^^^^^^^^^ >>>>>> File "/usr/lib64/python3.12/subprocess.py", line 466, in >>>>>> check_output >>>>>> return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, >>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> File "/usr/lib64/python3.12/subprocess.py", line 571, in run >>>>>> raise CalledProcessError(retcode, process.args, >>>>>> subprocess.CalledProcessError: Command '['objdump', '-d', '-z', >>>>>> '--start-address=0xffff80008125b758', >>>>>> '--stop-address=0xffff80008125a934', '../../vmlinux']' returned >>>>>> non-zero exit status 1. >>>>>> Fatal Python error: handler_call_die: problem in Python trace >>>>>> event handler >>>>>> Python runtime state: initialized >>>>>> >>>>>> Current thread 0x0000ffffb90d54e0 (most recent call first): >>>>>> <no Python frame> >>>>>> >>>>>> Extension modules: perf_trace_context, systemd._journal, >>>>>> systemd._reader, systemd.id128, report._py3report, _dbus_bindings, >>>>>> problem._py3abrt (total: 7) >>>>>> Aborted (core dumped) >>>>>> >>>>>> >>>>>> dump snippet: >>>>>> ============ >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff80008030cb00 phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff800080313f0c pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> ffff800080313f04 <__perf_event_header__init_id+0x4c>: >>>>>> ffff800080313f04: 36100094 tbz w20, #2, >>>>>> ffff800080313f14 <__perf_event_header__init_id+0x5c> >>>>>> ffff800080313f08: f941e6a0 ldr x0, [x21, >>>>>> #968] >>>>>> ffff800080313f0c: d63f0000 blr x0 >>>>>> perf 12720/12720 [0001] 5986.372298040 >>>>>> __perf_event_header__init_id+0x54 >>>>>> .../coresight/linux/kernel/events/core.c 586 return >>>>>> event->clock(); >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff8000801bb4a8 phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff80008030cb0c pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> ffff80008030cb00 <local_clock>: >>>>>> ffff80008030cb00: d503233f paciasp >>>>>> ffff80008030cb04: a9bf7bfd stp x29, x30, >>>>>> [sp, #-16]! >>>>>> ffff80008030cb08: 910003fd mov x29, sp >>>>>> ffff80008030cb0c: 97faba67 bl >>>>>> ffff8000801bb4a8 <sched_clock> >>>>>> perf 12720/12720 [0001] 5986.372298040 >>>>>> local_clock+0xc ...t/linux/./include/linux/sched/clock.h 64 >>>>>> return sched_clock(); >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff80008125a8a8 phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff8000801bb4c8 pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> ffff8000801bb4a8 <sched_clock>: >>>>>> ffff8000801bb4a8: d503233f paciasp >>>>>> ffff8000801bb4ac: a9be7bfd stp x29, x30, >>>>>> [sp, #-32]! >>>>>> ffff8000801bb4b0: 910003fd mov x29, sp >>>>>> ffff8000801bb4b4: a90153f3 stp x19, x20, >>>>>> [sp, #16] >>>>>> ffff8000801bb4b8: d5384113 mrs x19, sp_el0 >>>>>> ffff8000801bb4bc: b9401260 ldr w0, [x19, >>>>>> #16] >>>>>> ffff8000801bb4c0: 11000400 add w0, w0, #0x1 >>>>>> ffff8000801bb4c4: b9001260 str w0, [x19, >>>>>> #16] >>>>>> ffff8000801bb4c8: 94427cf8 bl >>>>>> ffff80008125a8a8 <sched_clock_noinstr> >>>>>> perf 12720/12720 [0001] 5986.372298040 >>>>>> sched_clock+0x20 ...sight/linux/kernel/time/sched_clock.c 105 ns >>>>>> = sched_clock_noinstr(); >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff80008125b758 phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff80008125a8e4 pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> ffff80008125a8a8 <sched_clock_noinstr>: >>>>>> ffff80008125a8a8: d503233f paciasp >>>>>> ffff80008125a8ac: a9bc7bfd stp x29, x30, >>>>>> [sp, #-64]! >>>>>> ffff80008125a8b0: 910003fd mov x29, sp >>>>>> ffff80008125a8b4: a90153f3 stp x19, x20, >>>>>> [sp, #16] >>>>>> ffff80008125a8b8: b000e354 adrp x20, >>>>>> ffff800082ec3000 <tick_bc_dev+0x140> >>>>>> ffff80008125a8bc: 910d0294 add x20, x20, >>>>>> #0x340 >>>>>> ffff80008125a8c0: a90363f7 stp x23, x24, >>>>>> [sp, #48] >>>>>> ffff80008125a8c4: 91002297 add x23, x20, >>>>>> #0x8 >>>>>> ffff80008125a8c8: 52800518 mov w24, >>>>>> #0x28 // #40 >>>>>> ffff80008125a8cc: a9025bf5 stp x21, x22, >>>>>> [sp, #32] >>>>>> ffff80008125a8d0: b9400296 ldr w22, [x20] >>>>>> ffff80008125a8d4: 120002d5 and w21, w22, >>>>>> #0x1 >>>>>> ffff80008125a8d8: 9bb87eb5 umull x21, w21, >>>>>> w24 >>>>>> ffff80008125a8dc: 8b1502f3 add x19, x23, >>>>>> x21 >>>>>> ffff80008125a8e0: f9400e60 ldr x0, [x19, >>>>>> #24] >>>>>> ffff80008125a8e4: d63f0000 blr x0 >>>>>> perf 12720/12720 [0001] 5986.372298040 >>>>>> sched_clock_noinstr+0x3c ...sight/linux/kernel/time/sched_clock.c >>>>>> 93 cyc = (rd->read_sched_clock() - rd->epoch_cyc) & >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff8000801bb4cc phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff80008125a930 pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> >>>>>> >>>>>> With fix: >>>>>> ========= >>>>>> >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff80008030cb00 phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff800080313f0c pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> ffff800080313f04 <__perf_event_header__init_id+0x4c>: >>>>>> ffff800080313f04: 36100094 tbz w20, #2, >>>>>> ffff800080313f14 <__perf_event_header__init_id+0x5c> >>>>>> ffff800080313f08: f941e6a0 ldr x0, [x21, >>>>>> #968] >>>>>> ffff800080313f0c: d63f0000 blr x0 >>>>>> perf 12720/12720 [0001] 5986.372298040 >>>>>> __perf_event_header__init_id+0x54 >>>>>> .../coresight/linux/kernel/events/core.c 586 return >>>>>> event->clock(); >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff8000801bb4a8 phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff80008030cb0c pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> ffff80008030cb00 <local_clock>: >>>>>> ffff80008030cb00: d503233f paciasp >>>>>> ffff80008030cb04: a9bf7bfd stp x29, x30, >>>>>> [sp, #-16]! >>>>>> ffff80008030cb08: 910003fd mov x29, sp >>>>>> ffff80008030cb0c: 97faba67 bl >>>>>> ffff8000801bb4a8 <sched_clock> >>>>>> perf 12720/12720 [0001] 5986.372298040 >>>>>> local_clock+0xc ...t/linux/./include/linux/sched/clock.h 64 >>>>>> return sched_clock(); >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff80008125a8a8 phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff8000801bb4c8 pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> ffff8000801bb4a8 <sched_clock>: >>>>>> ffff8000801bb4a8: d503233f paciasp >>>>>> ffff8000801bb4ac: a9be7bfd stp x29, x30, >>>>>> [sp, #-32]! >>>>>> ffff8000801bb4b0: 910003fd mov x29, sp >>>>>> ffff8000801bb4b4: a90153f3 stp x19, x20, >>>>>> [sp, #16] >>>>>> ffff8000801bb4b8: d5384113 mrs x19, sp_el0 >>>>>> ffff8000801bb4bc: b9401260 ldr w0, [x19, >>>>>> #16] >>>>>> ffff8000801bb4c0: 11000400 add w0, w0, #0x1 >>>>>> ffff8000801bb4c4: b9001260 str w0, [x19, >>>>>> #16] >>>>>> ffff8000801bb4c8: 94427cf8 bl >>>>>> ffff80008125a8a8 <sched_clock_noinstr> >>>>>> perf 12720/12720 [0001] 5986.372298040 >>>>>> sched_clock+0x20 ...sight/linux/kernel/time/sched_clock.c 105 ns >>>>>> = sched_clock_noinstr(); >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff80008125b758 phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff80008125a8e4 pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> ffff80008125a8a8 <sched_clock_noinstr>: >>>>>> ffff80008125a8a8: d503233f paciasp >>>>>> ffff80008125a8ac: a9bc7bfd stp x29, x30, >>>>>> [sp, #-64]! >>>>>> ffff80008125a8b0: 910003fd mov x29, sp >>>>>> ffff80008125a8b4: a90153f3 stp x19, x20, >>>>>> [sp, #16] >>>>>> ffff80008125a8b8: b000e354 adrp x20, >>>>>> ffff800082ec3000 <tick_bc_dev+0x140> >>>>>> ffff80008125a8bc: 910d0294 add x20, x20, >>>>>> #0x340 >>>>>> ffff80008125a8c0: a90363f7 stp x23, x24, >>>>>> [sp, #48] >>>>>> ffff80008125a8c4: 91002297 add x23, x20, >>>>>> #0x8 >>>>>> ffff80008125a8c8: 52800518 mov w24, >>>>>> #0x28 // #40 >>>>>> ffff80008125a8cc: a9025bf5 stp x21, x22, >>>>>> [sp, #32] >>>>>> ffff80008125a8d0: b9400296 ldr w22, [x20] >>>>>> ffff80008125a8d4: 120002d5 and w21, w22, >>>>>> #0x1 >>>>>> ffff80008125a8d8: 9bb87eb5 umull x21, w21, >>>>>> w24 >>>>>> ffff80008125a8dc: 8b1502f3 add x19, x23, >>>>>> x21 >>>>>> ffff80008125a8e0: f9400e60 ldr x0, [x19, >>>>>> #24] >>>>>> ffff80008125a8e4: d63f0000 blr x0 >>>>> >>>>> It looks like the disassembly now assumes this BLR wasn't taken. We >>>>> go from ffff80008125a8e4 straight through to ... >>>>> >>>>>> perf 12720/12720 [0001] 5986.372298040 >>>>>> sched_clock_noinstr+0x3c ...sight/linux/kernel/time/sched_clock.c >>>>>> 93 cyc = (rd->read_sched_clock() - rd->epoch_cyc) & >>>>>> Event type: branches >>>>>> Sample = { cpu: 0001 addr: 0xffff8000801bb4cc phys_addr: >>>>>> 0x0000000000000000 ip: 0xffff80008125a930 pid: 12720 tid: 12720 >>>>>> period: 1 time: 5986372298040 } >>>>>> ffff80008125a8e8 <sched_clock_noinstr+0x40>: >>>>>> ffff80008125a8e8: f8756ae3 ldr x3, [x23, >>>>>> x21] >>>>> >>>>> ffff80008125a8e4 which is just the previous one +4. Isn't your >>>>> issue actually a decode issue in Perf itself? Why is there a >>>>> discontinuity without branch samples being generated where either >>>>> the source or destination address is 0? >>>>> >>>>> What are your record options to create this issue? As I mentioned >>>>> in the previous reply I haven't been able to reproduce it. >>>> >>>> I am using below perf record command. >>>> >>>> timeout 4s ./perf record -e cs_etm// -C 1 dd if=/dev/zero of=/dev/null >>>> >>> >>> Thanks I managed to reproduce it. I'll take a look to see if I think >>> the issue is somewhere else. >>> >> >> At least for the failures I encountered, the issue is due to the >> alternatives runtime instruction patching mechanism. vmlinux ends up >> being the wrong image to decode with because a load of branches are >> actually turned into nops. >> >> Can you confirm if you use --kcore instead of vmlinux that you still >> get failures: >> >> sudo perf record -e cs_etm// -C 1 --kcore -o <output-folder.data> -- \ >> dd if=/dev/zero of=/dev/null >> >> perf script -i <output-folder.data> \ >> tools/perf/scripts/python/arm-cs-trace-disasm.py -d llvm-objdump \ >> -k <output-folder.data>/kcore_dir/kcore >> > > With below command combination with kcore also the issue is seen, as > reported in this email chain. > > timeout 8s ./perf record -e cs_etm// -C 1 --kcore -o kcore \ > dd if=/dev/zero of=/dev/null > > ./perf script -i kcore/data \ > --script=python:./scripts/python/arm-cs-trace-disasm.py -- \ > -d objdump -k kcore/kcore_dir/kcore > > > However, with below sequence(same as your command) the issue is *not* seen. > > timeout 8s ./perf record -e cs_etm// -C 1 --kcore -o kcore \ > dd if=/dev/zero of=/dev/null > > ./perf script -i kcore/data ./scripts/python/arm-cs-trace-disasm.py \ > -- -d objdump -k kcore/kcore_dir/kcore > > Do you see any issue with the command, which is showing the problem? > Also the output log produced by these both commands is different. > Double check the command I gave. "-i" needs to be the same as "-o" (it's the folder, not the data file). I think this could be causing your issue. Unless you give it the folder it doesn't open kcore along with the data file. > The below diff that you have shared has no effect on the failing case. > >> But I still think bad decode detection should be moved as much as >> possible into OpenCSD and Perf rather than this script. Otherwise >> every tool will have to re-implement it, and OpenCSD has a lot more >> info to make decisions with. >> >> One change we can make is to desynchronize when an N atom is an >> unconditional branch: >> >> diff --git a/decoder/source/etmv4/trc_pkt_decode_etmv4i.cpp >> b/decoder/source/etmv4/trc_pkt_decode_etmv4i.cpp >> index c557998..3eefd5d 100644 >> --- a/decoder/source/etmv4/trc_pkt_decode_etmv4i.cpp >> +++ b/decoder/source/etmv4/trc_pkt_decode_etmv4i.cpp >> @@ -1341,6 +1341,14 @@ ocsd_err_t >> TrcPktDecodeEtmV4I::processAtom(const ocsd_atm_val atom) >> // save recorded next instuction address >> ocsd_vaddr_t nextAddr = m_instr_info.instr_addr; >> >> + // must have lost sync if an unconditional branch wasn't taken >> + if (atom == ATOM_N && !m_instr_info.is_conditional) { >> + m_need_addr = true; >> + m_out_elem.addElemType(m_index_curr_pkt, >> OCSD_GEN_TRC_ELEM_NO_SYNC); >> + // wait for next address >> + return OCSD_OK; >> + } >> + >> >> Another one we can spot is when a new address comes that is before the >> current decode address (basically the backwards check that you added). >> >> There are probably others that can be spotted like an address >> appearing after a direct branch that doesn't match the branch target. >> >> I think at that point, desynchronising should cause the disassembly >> script to throw away the last bit, rather than force it to be printed >> as in this patch. As I mentioned above in the thread, it leads to >> printing disassembly that's implausible and misleading (where an >> unconditional branch wasn't taken). > > Thanks, > Ganapat

1 year

Re: [PATCH 1/4] coresight: cti: use device_* to iterate over device child nodes

by Suzuki K Poulose

On 01/08/2024 11:37, Javier Carrasco wrote: > On 01/08/2024 11:20, Suzuki K Poulose wrote: >> On 01/08/2024 07:13, Javier Carrasco wrote: >>> Drop the manual access to the fwnode of the device to iterate over its >>> child nodes. `device_for_each_child_node` macro provides direct access >>> to the child nodes, and given that they are only required within the >>> loop, the scoped variant of the macro can be used. >>> >>> Use the `device_for_each_child_node_scoped` macro to iterate over the >>> direct child nodes of the device. >>> >>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> >>> --- >>> drivers/hwtracing/coresight/coresight-cti-platform.c | 10 +++------- >>> 1 file changed, 3 insertions(+), 7 deletions(-) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight-cti-platform.c b/ >>> drivers/hwtracing/coresight/coresight-cti-platform.c >>> index ccef04f27f12..d0ae10bf6128 100644 >>> --- a/drivers/hwtracing/coresight/coresight-cti-platform.c >>> +++ b/drivers/hwtracing/coresight/coresight-cti-platform.c >>> @@ -416,20 +416,16 @@ static int >>> cti_plat_create_impdef_connections(struct device *dev, >>> struct cti_drvdata *drvdata) >>> { >>> int rc = 0; >>> - struct fwnode_handle *fwnode = dev_fwnode(dev); >>> - struct fwnode_handle *child = NULL; >>> - if (IS_ERR_OR_NULL(fwnode)) >>> + if (IS_ERR_OR_NULL(dev_fwnode(dev))) >>> return -EINVAL; >>> - fwnode_for_each_child_node(fwnode, child) { >>> + device_for_each_child_node_scoped(dev, child) { >>> if (cti_plat_node_name_eq(child, CTI_DT_CONNS)) >>> - rc = cti_plat_create_connection(dev, drvdata, >>> - child); >>> + rc = cti_plat_create_connection(dev, drvdata, child); >>> if (rc != 0) >>> break; >> >> Don't we need to fwnode_handle_put(child) here, since we removed the >> outer one ? >> >> Suzuki >> > > Hi Suzuki, > > No, we don't need fwnode_handle_put(child) anymore because the scoped > variant of the macro is used. Ah, apologies, was looking at the non-scoped version. I will queue this. Suzuki > > Best regards, > Javier Carrasco

1 year

Re: [PATCH v1 4/6] perf auxtrace: Iterate all AUX events when finish reading

by Arnaldo Carvalho de Melo

On Wed, Jul 31, 2024 at 06:38:59PM -0700, Ian Rogers wrote: > Just a heads up. Arnaldo added this to tmp.perf-tools-next and it > caused the intel-pt tests to start failing: My plan right now is just to remove that cset that Ian bisected since it is not on perf-tools-next, just on the scratch branch tmp.perf-tools-next. Trying to do that now as it will help us with bisection in the future. - Arnaldo > ``` > $ perf test 118 -v > 118: Miscellaneous Intel PT testing: > --- start --- > test child forked, pid 148999 > --- Test system-wide sideband --- > Checking for CPU-wide recording on CPU 0 > OK > Checking for CPU-wide recording on CPU 1 > OK > Linux > Failed to enable event (idx=0): -22 > Failed to record MMAP events on CPU 1 when tracing CPU 0 > ... > ``` > It's likely Adrian's comments already address this but you may also > want to double check this test is passing with v2. > > Thanks, > Ian

1 year

Re: [PATCH] perf scripts python arm-cs-trace-disasm.py: Skip disasm if address continuity is broken

by James Clark

On 24/07/2024 7:38 am, Ganapatrao Kulkarni wrote: > > > On 23-07-2024 09:16 pm, James Clark wrote: >> >> >> On 23/07/2024 4:26 pm, Ganapatrao Kulkarni wrote: >>> >>> >>> On 23-07-2024 06:40 pm, James Clark wrote: >>>> >>>> >>>> On 22/07/2024 11:02 am, Ganapatrao Kulkarni wrote: >>>>> >>>>> Hi James, >>>>> >>>>> On 19-07-2024 08:09 pm, James Clark wrote: >>>>>> >>>>>> >>>>>> On 19/07/2024 10:26 am, Ganapatrao Kulkarni wrote: >>>>>>> To generate the instruction tracing, script uses 2 contiguous >>>>>>> packets >>>>>>> address range. If there a continuity brake due to discontiguous >>>>>>> branch >>>>>>> address, it is required to reset the tracing and start tracing >>>>>>> with the >>>>>>> new set of contiguous packets. >>>>>>> >>>>>>> Adding change to identify the break and complete the remaining >>>>>>> tracing >>>>>>> of current packets and restart tracing from new set of packets, if >>>>>>> continuity is established. >>>>>>> >>>>>> >>>>>> Hi Ganapatrao, >>>>>> >>>>>> Can you add a before and after example of what's changed to the >>>>>> commit message? It wasn't immediately obvious to me if this is >>>>>> adding missing output, or it was correcting the tail end of the >>>>>> output that was previously wrong. >>>>> >>>>> It is adding tail end of the trace as well avoiding the segfault of >>>>> the perf application. With out this change the perf segfaults with >>>>> as below log >>>>> >>>>> >>>>> ./perf script >>>>> --script=python:./scripts/python/arm-cs-trace-disasm.py -- -d >>>>> objdump -k ../../vmlinux -v $* > dump >>>>> objdump: error: the stop address should be after the start address >>>>> Traceback (most recent call last): >>>>> File "./scripts/python/arm-cs-trace-disasm.py", line 271, in >>>>> process_event >>>>> print_disam(dso_fname, dso_vm_start, start_addr, stop_addr) >>>>> File "./scripts/python/arm-cs-trace-disasm.py", line 105, in >>>>> print_disam >>>>> for line in read_disam(dso_fname, dso_start, start_addr, >>>>> stop_addr): >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> File "./scripts/python/arm-cs-trace-disasm.py", line 99, in >>>>> read_disam >>>>> disasm_output = check_output(disasm).decode('utf-8').split('\n') >>>>> ^^^^^^^^^^^^^^^^^^^^ >>>>> File "/usr/lib64/python3.12/subprocess.py", line 466, in >>>>> check_output >>>>> return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> File "/usr/lib64/python3.12/subprocess.py", line 571, in run >>>>> raise CalledProcessError(retcode, process.args, >>>>> subprocess.CalledProcessError: Command '['objdump', '-d', '-z', >>>>> '--start-address=0xffff80008125b758', >>>>> '--stop-address=0xffff80008125a934', '../../vmlinux']' returned >>>>> non-zero exit status 1. >>>>> Fatal Python error: handler_call_die: problem in Python trace event >>>>> handler >>>>> Python runtime state: initialized >>>>> >>>>> Current thread 0x0000ffffb05054e0 (most recent call first): >>>>> <no Python frame> >>>>> >>>>> Extension modules: perf_trace_context, systemd._journal, >>>>> systemd._reader, systemd.id128, report._py3report, _dbus_bindings, >>>>> problem._py3abrt (total: 7) >>>>> Aborted (core dumped) >>>>> >>>>>> >>>>>>> Signed-off-by: Ganapatrao Kulkarni >>>>>>> <gankulkarni(a)os.amperecomputing.com> >>>>>>> --- >>>>>>> tools/perf/scripts/python/arm-cs-trace-disasm.py | 10 ++++++++++ >>>>>>> 1 file changed, 10 insertions(+) >>>>>>> >>>>>>> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>>> b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>>> index d973c2baed1c..ad10cee2c35e 100755 >>>>>>> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>>> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>>>>>> @@ -198,6 +198,10 @@ def process_event(param_dict): >>>>>>> cpu_data[str(cpu) + 'addr'] = addr >>>>>>> return >>>>>>> + if (cpu_data.get(str(cpu) + 'ip') == None): >>>>>>> + cpu_data[str(cpu) + 'ip'] = ip >>>>>>> + >>>>>> >>>>>> Do you need to write into the global cpu_data here? Doesn't it get >>>>>> overwritten after you load it back into 'prev_ip' >>>>> >>>>> No, the logic is same as holding the addr of previous packet. >>>>> Saving the previous packet saved ip in to prev_ip before >>>>> overwriting with the current packet. >>>> >>>> It's not exactly the same logic as holding the addr of the previous >>>> sample. For addr, we return on the first None, with your change we >>>> now "pretend" that the second one is also the previous one: >>>> >>>> if (cpu_data.get(str(cpu) + 'addr') == None): >>>> cpu_data[str(cpu) + 'addr'] = addr >>>> return <----------------------------sample 0 return >>>> >>>> if (cpu_data.get(str(cpu) + 'ip') == None): >>>> cpu_data[str(cpu) + 'ip'] = ip <---- sample 1 save but no return >>>> >>>> Then for sample 1 'prev_ip' is actually now the 'current' IP: >>> >>> Yes, it is dummy for first packet. Added anticipating that we wont >>> hit the discontinuity for the first packet itself. >>> >>> Can this be changed to more intuitive like below? >>> >>> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>> b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>> index d973c2baed1c..d49f5090059f 100755 >>> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>> @@ -198,6 +198,8 @@ def process_event(param_dict): >>> cpu_data[str(cpu) + 'addr'] = addr >>> return >>> >>> + if (cpu_data.get(str(cpu) + 'ip') != None): >>> + prev_ip = cpu_data[str(cpu) + 'ip'] >>> >>> if (options.verbose == True): >>> print("Event type: %s" % name) >>> @@ -243,12 +245,18 @@ def process_event(param_dict): >>> >>> # Record for previous sample packet >>> cpu_data[str(cpu) + 'addr'] = addr >>> + cpu_data[str(cpu) + 'ip'] = stop_addr >>> >>> # Handle CS_ETM_TRACE_ON packet if start_addr=0 and stop_addr=4 >>> if (start_addr == 0 and stop_addr == 4): >>> print("CPU%d: CS_ETM_TRACE_ON packet is inserted" % >>> cpu) >>> return >>> >>> + if (stop_addr < start_addr and prev_ip != 0): >>> + # Continuity of the Packets broken, set start_addr to >>> previous >>> + # packet ip to complete the remaining tracing of the >>> address range. >>> + start_addr = prev_ip >>> + >>> if (start_addr < int(dso_start) or start_addr > int(dso_end)): >>> print("Start address 0x%x is out of range [ 0x%x .. >>> 0x%x ] for dso %s" % (start_addr, int(dso_start), int(dso_end), dso)) >>> return >>> >>> Without this patch below is the failure log(with segfault) for >>> reference. >>> >>> [root@sut01sys-r214 perf]# timeout 4s ./perf record -e cs_etm// -C 1 >>> dd if=/dev/zero of=/dev/null >>> [ perf record: Woken up 1 times to write data ] >>> [ perf record: Captured and wrote 1.087 MB perf.data ] >>> [root@sut01sys-r214 perf]# ./perf script >>> --script=python:./scripts/python/arm-cs-trace-disasm.py -- -d objdump >>> -k ../../vmlinux -v $* > dump >>> objdump: error: the stop address should be after the start address >>> Traceback (most recent call last): >>> File "./scripts/python/arm-cs-trace-disasm.py", line 271, in >>> process_event >>> print_disam(dso_fname, dso_vm_start, start_addr, stop_addr) >>> File "./scripts/python/arm-cs-trace-disasm.py", line 105, in >>> print_disam >>> for line in read_disam(dso_fname, dso_start, start_addr, >>> stop_addr): >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> File "./scripts/python/arm-cs-trace-disasm.py", line 99, in >>> read_disam >>> disasm_output = check_output(disasm).decode('utf-8').split('\n') >>> ^^^^^^^^^^^^^^^^^^^^ >>> File "/usr/lib64/python3.12/subprocess.py", line 466, in check_output >>> return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> File "/usr/lib64/python3.12/subprocess.py", line 571, in run >>> raise CalledProcessError(retcode, process.args, >>> subprocess.CalledProcessError: Command '['objdump', '-d', '-z', >>> '--start-address=0xffff80008125b758', >>> '--stop-address=0xffff80008125a934', '../../vmlinux']' returned >>> non-zero exit status 1. >>> Fatal Python error: handler_call_die: problem in Python trace event >>> handler >>> Python runtime state: initialized >>> >>> Current thread 0x0000ffffb90d54e0 (most recent call first): >>> <no Python frame> >>> >>> Extension modules: perf_trace_context, systemd._journal, >>> systemd._reader, systemd.id128, report._py3report, _dbus_bindings, >>> problem._py3abrt (total: 7) >>> Aborted (core dumped) >>> >>> >>> dump snippet: >>> ============ >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff80008030cb00 phys_addr: >>> 0x0000000000000000 ip: 0xffff800080313f0c pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> ffff800080313f04 <__perf_event_header__init_id+0x4c>: >>> ffff800080313f04: 36100094 tbz w20, #2, >>> ffff800080313f14 <__perf_event_header__init_id+0x5c> >>> ffff800080313f08: f941e6a0 ldr x0, [x21, #968] >>> ffff800080313f0c: d63f0000 blr x0 >>> perf 12720/12720 [0001] 5986.372298040 >>> __perf_event_header__init_id+0x54 >>> .../coresight/linux/kernel/events/core.c 586 return >>> event->clock(); >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff8000801bb4a8 phys_addr: >>> 0x0000000000000000 ip: 0xffff80008030cb0c pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> ffff80008030cb00 <local_clock>: >>> ffff80008030cb00: d503233f paciasp >>> ffff80008030cb04: a9bf7bfd stp x29, x30, >>> [sp, #-16]! >>> ffff80008030cb08: 910003fd mov x29, sp >>> ffff80008030cb0c: 97faba67 bl ffff8000801bb4a8 >>> <sched_clock> >>> perf 12720/12720 [0001] 5986.372298040 >>> local_clock+0xc ...t/linux/./include/linux/sched/clock.h 64 return >>> sched_clock(); >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff80008125a8a8 phys_addr: >>> 0x0000000000000000 ip: 0xffff8000801bb4c8 pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> ffff8000801bb4a8 <sched_clock>: >>> ffff8000801bb4a8: d503233f paciasp >>> ffff8000801bb4ac: a9be7bfd stp x29, x30, >>> [sp, #-32]! >>> ffff8000801bb4b0: 910003fd mov x29, sp >>> ffff8000801bb4b4: a90153f3 stp x19, x20, >>> [sp, #16] >>> ffff8000801bb4b8: d5384113 mrs x19, sp_el0 >>> ffff8000801bb4bc: b9401260 ldr w0, [x19, #16] >>> ffff8000801bb4c0: 11000400 add w0, w0, #0x1 >>> ffff8000801bb4c4: b9001260 str w0, [x19, #16] >>> ffff8000801bb4c8: 94427cf8 bl ffff80008125a8a8 >>> <sched_clock_noinstr> >>> perf 12720/12720 [0001] 5986.372298040 >>> sched_clock+0x20 ...sight/linux/kernel/time/sched_clock.c 105 ns = >>> sched_clock_noinstr(); >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff80008125b758 phys_addr: >>> 0x0000000000000000 ip: 0xffff80008125a8e4 pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> ffff80008125a8a8 <sched_clock_noinstr>: >>> ffff80008125a8a8: d503233f paciasp >>> ffff80008125a8ac: a9bc7bfd stp x29, x30, >>> [sp, #-64]! >>> ffff80008125a8b0: 910003fd mov x29, sp >>> ffff80008125a8b4: a90153f3 stp x19, x20, >>> [sp, #16] >>> ffff80008125a8b8: b000e354 adrp x20, >>> ffff800082ec3000 <tick_bc_dev+0x140> >>> ffff80008125a8bc: 910d0294 add x20, x20, >>> #0x340 >>> ffff80008125a8c0: a90363f7 stp x23, x24, >>> [sp, #48] >>> ffff80008125a8c4: 91002297 add x23, x20, #0x8 >>> ffff80008125a8c8: 52800518 mov w24, #0x28 >>> // #40 >>> ffff80008125a8cc: a9025bf5 stp x21, x22, >>> [sp, #32] >>> ffff80008125a8d0: b9400296 ldr w22, [x20] >>> ffff80008125a8d4: 120002d5 and w21, w22, #0x1 >>> ffff80008125a8d8: 9bb87eb5 umull x21, w21, w24 >>> ffff80008125a8dc: 8b1502f3 add x19, x23, x21 >>> ffff80008125a8e0: f9400e60 ldr x0, [x19, #24] >>> ffff80008125a8e4: d63f0000 blr x0 >>> perf 12720/12720 [0001] 5986.372298040 >>> sched_clock_noinstr+0x3c ...sight/linux/kernel/time/sched_clock.c >>> 93 cyc = (rd->read_sched_clock() - rd->epoch_cyc) & >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff8000801bb4cc phys_addr: >>> 0x0000000000000000 ip: 0xffff80008125a930 pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> >>> >>> With fix: >>> ========= >>> >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff80008030cb00 phys_addr: >>> 0x0000000000000000 ip: 0xffff800080313f0c pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> ffff800080313f04 <__perf_event_header__init_id+0x4c>: >>> ffff800080313f04: 36100094 tbz w20, #2, >>> ffff800080313f14 <__perf_event_header__init_id+0x5c> >>> ffff800080313f08: f941e6a0 ldr x0, [x21, #968] >>> ffff800080313f0c: d63f0000 blr x0 >>> perf 12720/12720 [0001] 5986.372298040 >>> __perf_event_header__init_id+0x54 >>> .../coresight/linux/kernel/events/core.c 586 return >>> event->clock(); >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff8000801bb4a8 phys_addr: >>> 0x0000000000000000 ip: 0xffff80008030cb0c pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> ffff80008030cb00 <local_clock>: >>> ffff80008030cb00: d503233f paciasp >>> ffff80008030cb04: a9bf7bfd stp x29, x30, >>> [sp, #-16]! >>> ffff80008030cb08: 910003fd mov x29, sp >>> ffff80008030cb0c: 97faba67 bl ffff8000801bb4a8 >>> <sched_clock> >>> perf 12720/12720 [0001] 5986.372298040 >>> local_clock+0xc ...t/linux/./include/linux/sched/clock.h 64 return >>> sched_clock(); >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff80008125a8a8 phys_addr: >>> 0x0000000000000000 ip: 0xffff8000801bb4c8 pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> ffff8000801bb4a8 <sched_clock>: >>> ffff8000801bb4a8: d503233f paciasp >>> ffff8000801bb4ac: a9be7bfd stp x29, x30, >>> [sp, #-32]! >>> ffff8000801bb4b0: 910003fd mov x29, sp >>> ffff8000801bb4b4: a90153f3 stp x19, x20, >>> [sp, #16] >>> ffff8000801bb4b8: d5384113 mrs x19, sp_el0 >>> ffff8000801bb4bc: b9401260 ldr w0, [x19, #16] >>> ffff8000801bb4c0: 11000400 add w0, w0, #0x1 >>> ffff8000801bb4c4: b9001260 str w0, [x19, #16] >>> ffff8000801bb4c8: 94427cf8 bl ffff80008125a8a8 >>> <sched_clock_noinstr> >>> perf 12720/12720 [0001] 5986.372298040 >>> sched_clock+0x20 ...sight/linux/kernel/time/sched_clock.c 105 ns = >>> sched_clock_noinstr(); >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff80008125b758 phys_addr: >>> 0x0000000000000000 ip: 0xffff80008125a8e4 pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> ffff80008125a8a8 <sched_clock_noinstr>: >>> ffff80008125a8a8: d503233f paciasp >>> ffff80008125a8ac: a9bc7bfd stp x29, x30, >>> [sp, #-64]! >>> ffff80008125a8b0: 910003fd mov x29, sp >>> ffff80008125a8b4: a90153f3 stp x19, x20, >>> [sp, #16] >>> ffff80008125a8b8: b000e354 adrp x20, >>> ffff800082ec3000 <tick_bc_dev+0x140> >>> ffff80008125a8bc: 910d0294 add x20, x20, >>> #0x340 >>> ffff80008125a8c0: a90363f7 stp x23, x24, >>> [sp, #48] >>> ffff80008125a8c4: 91002297 add x23, x20, #0x8 >>> ffff80008125a8c8: 52800518 mov w24, #0x28 >>> // #40 >>> ffff80008125a8cc: a9025bf5 stp x21, x22, >>> [sp, #32] >>> ffff80008125a8d0: b9400296 ldr w22, [x20] >>> ffff80008125a8d4: 120002d5 and w21, w22, #0x1 >>> ffff80008125a8d8: 9bb87eb5 umull x21, w21, w24 >>> ffff80008125a8dc: 8b1502f3 add x19, x23, x21 >>> ffff80008125a8e0: f9400e60 ldr x0, [x19, #24] >>> ffff80008125a8e4: d63f0000 blr x0 >> >> It looks like the disassembly now assumes this BLR wasn't taken. We go >> from ffff80008125a8e4 straight through to ... >> >>> perf 12720/12720 [0001] 5986.372298040 >>> sched_clock_noinstr+0x3c ...sight/linux/kernel/time/sched_clock.c >>> 93 cyc = (rd->read_sched_clock() - rd->epoch_cyc) & >>> Event type: branches >>> Sample = { cpu: 0001 addr: 0xffff8000801bb4cc phys_addr: >>> 0x0000000000000000 ip: 0xffff80008125a930 pid: 12720 tid: 12720 >>> period: 1 time: 5986372298040 } >>> ffff80008125a8e8 <sched_clock_noinstr+0x40>: >>> ffff80008125a8e8: f8756ae3 ldr x3, [x23, x21] >> >> ffff80008125a8e4 which is just the previous one +4. Isn't your issue >> actually a decode issue in Perf itself? Why is there a discontinuity >> without branch samples being generated where either the source or >> destination address is 0? >> >> What are your record options to create this issue? As I mentioned in >> the previous reply I haven't been able to reproduce it. > > I am using below perf record command. > > timeout 4s ./perf record -e cs_etm// -C 1 dd if=/dev/zero of=/dev/null > Thanks I managed to reproduce it. I'll take a look to see if I think the issue is somewhere else. >> > > Thanks, > Ganapat

1 year

Re: [PATCH 1/4] coresight: cti: use device_* to iterate over device child nodes

by Suzuki K Poulose

On 01/08/2024 07:13, Javier Carrasco wrote: > Drop the manual access to the fwnode of the device to iterate over its > child nodes. `device_for_each_child_node` macro provides direct access > to the child nodes, and given that they are only required within the > loop, the scoped variant of the macro can be used. > > Use the `device_for_each_child_node_scoped` macro to iterate over the > direct child nodes of the device. > > Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> > --- > drivers/hwtracing/coresight/coresight-cti-platform.c | 10 +++------- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-cti-platform.c b/drivers/hwtracing/coresight/coresight-cti-platform.c > index ccef04f27f12..d0ae10bf6128 100644 > --- a/drivers/hwtracing/coresight/coresight-cti-platform.c > +++ b/drivers/hwtracing/coresight/coresight-cti-platform.c > @@ -416,20 +416,16 @@ static int cti_plat_create_impdef_connections(struct device *dev, > struct cti_drvdata *drvdata) > { > int rc = 0; > - struct fwnode_handle *fwnode = dev_fwnode(dev); > - struct fwnode_handle *child = NULL; > > - if (IS_ERR_OR_NULL(fwnode)) > + if (IS_ERR_OR_NULL(dev_fwnode(dev))) > return -EINVAL; > > - fwnode_for_each_child_node(fwnode, child) { > + device_for_each_child_node_scoped(dev, child) { > if (cti_plat_node_name_eq(child, CTI_DT_CONNS)) > - rc = cti_plat_create_connection(dev, drvdata, > - child); > + rc = cti_plat_create_connection(dev, drvdata, child); > if (rc != 0) > break; Don't we need to fwnode_handle_put(child) here, since we removed the outer one ? Suzuki

1 year

[PATCH v4 0/2] coresight: core: Add device name support

by Mao Jinlong

With current design, the name of the non-cpu bounded coresight component is the device type with the number. And with 'ls' command we can get the register address of the component. But from these information, we can't know what the HW or system the component belongs to. Add device-name in DT to support it. cti_sys0 -> ../../../devices/platform/soc(a)0/138f0000.cti/cti_sys0 cti_sys1 -> ../../../devices/platform/soc(a)0/13900000.cti/cti_sys1 tpdm0 -> ../../../devices/platform/soc(a)0/10b0d000.tpdm/tpdm0 tpdm1 -> ../../../devices/platform/soc(a)0/10c28000.tpdm/tpdm1 tpdm2 -> ../../../devices/platform/soc(a)0/10c29000.tpdm/tpdm2 Change since V3: 1. Change device-name to arm,cs-dev-name. 2. Add arm,cs-dev-name to only CTI and sources' dt-binding. Change since V2: 1. Fix the error in coresight core. drivers/hwtracing/coresight/coresight-core.c:1775:7: error: assigning to 'char *' from 'const char *' discards qualifiers 2. Fix the warning when run dtbinding check. Documentation/devicetree/bindings/arm/arm,coresight-cpu-debug.yaml: device-name: missing type definition Change since V1: 1. Change coresight-name to device name. 2. Add the device-name in coresight dt bindings. Mao Jinlong (2): coresight: core: Add device name support dt-bindings: arm: Add device-name in the coresight components .../bindings/arm/arm,coresight-catu.yaml | 6 +++ .../bindings/arm/arm,coresight-cpu-debug.yaml | 6 +++ .../bindings/arm/arm,coresight-cti.yaml | 6 +++ .../arm/arm,coresight-dummy-sink.yaml | 6 +++ .../arm/arm,coresight-dummy-source.yaml | 6 +++ .../arm/arm,coresight-dynamic-funnel.yaml | 6 +++ .../arm/arm,coresight-dynamic-replicator.yaml | 6 +++ .../bindings/arm/arm,coresight-etb10.yaml | 6 +++ .../bindings/arm/arm,coresight-etm.yaml | 6 +++ .../arm/arm,coresight-static-funnel.yaml | 6 +++ .../arm/arm,coresight-static-replicator.yaml | 6 +++ .../bindings/arm/arm,coresight-stm.yaml | 6 +++ .../bindings/arm/arm,coresight-tmc.yaml | 6 +++ .../bindings/arm/arm,coresight-tpiu.yaml | 6 +++ .../bindings/arm/qcom,coresight-tpda.yaml | 6 +++ .../bindings/arm/qcom,coresight-tpdm.yaml | 6 +++ drivers/hwtracing/coresight/coresight-core.c | 37 ++++++++++--------- .../hwtracing/coresight/coresight-platform.c | 31 ++++++++++++++++ include/linux/coresight.h | 3 +- 19 files changed, 149 insertions(+), 18 deletions(-) Mao Jinlong (2): dt-bindings: arm: Add device-name in the coresight components coresight: core: Add device name support .../bindings/arm/arm,coresight-cti.yaml | 6 +++ .../arm/arm,coresight-dummy-source.yaml | 6 +++ .../bindings/arm/arm,coresight-stm.yaml | 6 +++ .../bindings/arm/qcom,coresight-tpdm.yaml | 6 +++ drivers/hwtracing/coresight/coresight-core.c | 37 ++++++++++--------- .../hwtracing/coresight/coresight-platform.c | 30 +++++++++++++++ include/linux/coresight.h | 3 +- 7 files changed, 76 insertions(+), 18 deletions(-) -- 2.41.0

1 year

Re: [PATCH v2 1/4] perf auxtrace: Iterate all AUX events when finish reading

by Arnaldo Carvalho de Melo

On Mon, Jul 29, 2024 at 09:48:57AM +0100, Leo Yan wrote: > On 7/25/2024 4:40 PM, Adrian Hunter wrote: > > On 25/07/24 09:46, Leo Yan wrote: > >> When finished to read AUX trace data from mmaped buffer, based on the > > > > Here and elsewhere 'mmapped' is more common than 'mmaped' so maybe: > > > > mmaped -> mmapped > > Will fix. > > >> AUX buffer index the core layer needs to search the corresponding PMU > >> event and re-enable it to continue tracing. > >> > >> However, current code only searches the first AUX event. It misses to > >> search other enabled AUX events, thus, it returns failure if the buffer > >> index does not belong to the first AUX event. > >> > >> This patch extends the auxtrace_record__read_finish() function to > >> search for every enabled AUX events, so all the mmaped buffer indexes > >> can be covered. > > > > Looking at this again, a couple more things came to mind - see below. > > > >> > >> Signed-off-by: Leo Yan <leo.yan(a)arm.com> > >> --- > >> tools/perf/util/auxtrace.c | 25 ++++++++++++++++++++----- > >> 1 file changed, 20 insertions(+), 5 deletions(-) > >> > >> diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c > >> index b99e72f7da88..61835a6a9ea3 100644 > >> --- a/tools/perf/util/auxtrace.c > >> +++ b/tools/perf/util/auxtrace.c > >> @@ -670,18 +670,33 @@ static int evlist__enable_event_idx(struct evlist *evlist, struct evsel *evsel, > >> int auxtrace_record__read_finish(struct auxtrace_record *itr, int idx) > >> { > >> struct evsel *evsel; > >> + int ret = -EINVAL; > >> > >> - if (!itr->evlist || !itr->pmu) > >> + if (!itr->evlist) > >> return -EINVAL; > >> > >> evlist__for_each_entry(itr->evlist, evsel) { > >> - if (evsel->core.attr.type == itr->pmu->type) { > >> + if (evsel__is_aux_event(evsel)) { > >> if (evsel->disabled) > >> - return 0; > >> - return evlist__enable_event_idx(itr->evlist, evsel, idx); > >> + continue; > > > > That will make the evsel->disabled case an error, which > > might be a problem. Possibly the event can be disabled > > (e.g. via control fifo) but still have data to read out. > > If so, we need to extend evlist__enable_event_idx() or create a new function > to check if the memory index is belonged to an evsel. If the idx is found for > an evsel, then we can check the evsel->disabled flag. > > >> + /* > >> + * Multiple AUX events might be opened in a session. > >> + * Bail out for success case as the AUX event has been > >> + * found and enabled, otherwise, continue to check if > >> + * the next AUX event can cover the mmaped buffer with > >> + * 'idx'. > >> + */ > > > > Thinking about this some more, raised some questions: > > > > How do we know there is only one AUX event per mmap? > > On my test platform, there have two Arm SPE events, the first one's cpumask is > 2-5 and the second SPE's cpumask is 6-7. The AUX events do not intersect CPU > maps. Therefore, a mmapped AUX buffer only binds to a AUX event. > > I think we can add a checking in the function record__auxtrace_init(). After > it calls auxtrace_record__init(), we can report failure if the AUX events have > the overlapped cpumask. > > > They would have to be on different CPUs for that to be true? > > Yes. > > > And wouldn't --per-thread have all AUX events in every mmap? > > Before I roughly tested '--per-thread' mode and did not see issue. But this > time I tested '--per-thread' mode and found the failure by the kernel checking > [1] - it does not allow the different AUX events to bind to the same FD. > > Here I need to dig a bit for two options, either we need to fix the perf > tool to open multiple AUX events for '--per-thread' mode, or remove the > kernel's checking to allow different AUX events to bind to same FD. > > Thanks a lot for review! Ok, the two patches from Adrian are in, I'll now wait for you to refresh this series, Thanks, - Arnaldo

1 year

Re: [PATCH V9 02/13] perf/core: Add aux_pause, aux_resume, aux_start_paused

by Arnaldo Carvalho de Melo

On Fri, Jul 26, 2024 at 07:00:55PM +0300, Adrian Hunter wrote: > On 26/07/24 17:41, Arnaldo Carvalho de Melo wrote: > > On Thu, Jul 18, 2024 at 06:06:16PM +0300, Adrian Hunter wrote: > >> On 18/07/24 15:58, Peter Zijlstra wrote: > >>> On Thu, Jul 18, 2024 at 01:51:26PM +0200, Peter Zijlstra wrote: > >>> > >>>> OK, let me do that and make a few more edits and see if I can stare at > >>>> that next patch some. > >>> > >>> I pushed out a stack of patches into queue.git perf/core > >>> Could you please double check I didn't wreck anything? > >> > >> Looks fine, and seems to work OK in a brief test. > >> > >> Thank you! :-) > > > > So should I go ahead and pick the tooling patches since the kernel bits > > are merged? > > Not exactly merged. Probably should wait until it is in tip at least. Ok, so I get just these, as you asked on another message: acme@x1:~/git/perf-tools-next$ git log --oneline -5 perf-tools-next/tmp.perf-tools-next 9140fec01b2de8d3 (HEAD -> perf-tools-next, perf-tools-next/tmp.perf-tools-next, perf-tools-next.korg/tmp.perf-tools-next, number/perf-tools-next, acme.korg/tmp.perf-tools-next) perf tools: Enable evsel__is_aux_event() to work for S390_CPUMSF c3b7dba6ea81a5b1 perf tools: Enable evsel__is_aux_event() to work for ARM/ARM64 866400c0b08ef9d9 perf scripts python cs-etm: Restore first sample log in verbose mode 08ee74eb03e37191 perf cs-etm: Output 0 instead of 0xdeadbeef when exception packets are flushed c22dd7ec2b2808b2 perf inject: Convert comma to semicolon acme@x1:~/git/perf-tools-next$ It'll go to perf-tools-next once 6.11-rc1 is out. - Arnaldo

1 year, 1 month

Re: [PATCH V9 06/13] perf tools: Enable evsel__is_aux_event() to work for S390_CPUMSF

by Arnaldo Carvalho de Melo

On Tue, Jul 23, 2024 at 12:09:46PM +0300, Adrian Hunter wrote: > On 23/07/24 11:26, Leo Yan wrote: > > On 7/15/2024 5:07 PM, Adrian Hunter wrote: > >> > >> evsel__is_aux_event() identifies AUX area tracing selected events. > >> > >> S390_CPUMSF uses a raw event type (PERF_TYPE_RAW - refer > >> s390_cpumsf_evsel_is_auxtrace()) not a PMU type value that could be checked > >> in evsel__is_aux_event(). However it sets needs_auxtrace_mmap (refer > >> auxtrace_record__init()), so check that first. > >> > >> Currently, the features that use evsel__is_aux_event() are used only by > >> Intel PT, but that may change in the future. > >> > >> Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> > >> Acked-by: Ian Rogers <irogers(a)google.com> > >> Reviewed-by: Andi Kleen <ak(a)linux.intel.com> > > > > Reviewed-by: Leo Yan <leo.yan(a)arm.com> > > Namhyung, could we get patches 5 and 6 from this series > applied? They are independent and Leo's new patch set is > dependent on patch 5. I'm getting those two into tmp.perf-tools-next, probably should pick the rest as peterz has the kernel bits already in his queue.git/perf/core, right? - Arnaldo > > > >> --- > >> tools/perf/util/pmu.c | 6 +++++- > >> 1 file changed, 5 insertions(+), 1 deletion(-) > >> > >> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c > >> index 986166bc7c78..0b38c51bd6eb 100644 > >> --- a/tools/perf/util/pmu.c > >> +++ b/tools/perf/util/pmu.c > >> @@ -1199,8 +1199,12 @@ void perf_pmu__warn_invalid_formats(struct perf_pmu *pmu) > >> > >> bool evsel__is_aux_event(const struct evsel *evsel) > >> { > >> - struct perf_pmu *pmu = evsel__find_pmu(evsel); > >> + struct perf_pmu *pmu; > >> > >> + if (evsel->needs_auxtrace_mmap) > >> + return true; > >> + > >> + pmu = evsel__find_pmu(evsel); > >> return pmu && pmu->auxtrace; > >> } > >> > >> -- > >> 2.34.1 > >> > >>

1 year, 1 month

Re: [PATCH V9 02/13] perf/core: Add aux_pause, aux_resume, aux_start_paused

by Arnaldo Carvalho de Melo

On Thu, Jul 18, 2024 at 06:06:16PM +0300, Adrian Hunter wrote: > On 18/07/24 15:58, Peter Zijlstra wrote: > > On Thu, Jul 18, 2024 at 01:51:26PM +0200, Peter Zijlstra wrote: > > > >> OK, let me do that and make a few more edits and see if I can stare at > >> that next patch some. > > > > I pushed out a stack of patches into queue.git perf/core > > Could you please double check I didn't wreck anything? > > Looks fine, and seems to work OK in a brief test. > > Thank you! :-) So should I go ahead and pick the tooling patches since the kernel bits are merged? - Arnaldo

1 year, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight