Good day Zied,
Apologies for the delay in responding to you - my mail client sent
your email to my spam folder. Moreover, I suggest to CC the coresight
mailing list when seeking guidance on this topic. There is a lot of
knowledgeable people on there that can help you as much as I can.
On Wed, 26 Jun 2019 at 06:47, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
> hi Mathieu,
>
> I was tracking the progress of coresight group within Linaro in providing coresight tracing in linux kernel as well as tools around it (e.g. perf, opencsd). I noticed that it reached a good maturity level to enable other use cases for this feature, one of them is providing non intrusive instruction tracing in GDB using ETM. This can bring a huge benefit to ARM community using open source tools (reduce debugging time, record and replay buggy execution, test coverage, performance analysis etc ..). in addition it can open the doors for business targeting introducing debuggers with ETM tracing support in the market with more affordable price.
>
> I would like to present this opportunity to Linaro, and I am seeking getting their feedback and involvement. I have seen that you were active since the beginning in the coresight project at Linaro, so you probably went through such a process. I want to get your advise on how to proceed to reach this target.
> I am attaching an RFC where technical aspects are discussed, this can give you a better insight on the use case and its realizability.
I commend you for taking the time to put this RFC together.
Integration of coresight with GDB is something that has been on the
radar for a long time. Several people have looked at the feature but
it was never pursued further for various reasons. Your RFC has a lot
of details and you definitely took time to think about this. Other
than that it is not possible for me to cast further judgement on the
viability of the project without a small prototype to evaluate and
code to look at.
I suggest you come up with a proof of concept that covers a basic
scenario. That will make it easier for us to review your work and
assess the feasibility of the feature. I also advise to take time to
understand how coresight has been integrated with perf, how
interactions with the openCSD library are made and the complexity
inherent to coresight trace decoding.
Thanks,
Mathieu
>
> looking forward for your feedback
> Best Regards
> Zied Guermazi
>
Hello,
I am trying to trace a statically linked application on my ZedBoard (Zynq-7000 SoC).
Please find attached the ELF file and the assembler file of the application.
For the context:
- The CPU0 runs at 333 MHz
- The TPIU runs at 200 MHz
- The PL (FPGA) runs at 250 MHz
For tracing the application, I use the attached script.sh file, which mainly:
- Disable the CPU1
- Setting up the address comparator
- Activate the Branch Broadcast mode
- Specify the address range to trace
- Activate the PTM and the TPIU
- Execute the application
- Retrieve the trace in a dedicated BRAM memory in the PL.
When I trace the whole .text section (from 0x100e0 to 0x15140)
I receive incomplete and inconsistent traces, for example:
00 9c 148d4 15d4c 10db4 13ecc b6fa3f44 14568 b6f85720 148d4 b6fa5d4c 13ecc b6fa3f44
14568 b6f85720 148d4 b6fa5d4c 147c0 b6f78030 14784 b6f6f3c8 13ecc b6f9df44 14704
b6f6f3c8 14784 b6f6f3c8 13d08 b6f9ea70 13d88 b6f9ea70 13c68 b6f99484 14628 b6f994b4
1485c b6fa0174 1452c b6faa2c4 14094 b6fabcb0 142b0 b6fab754 14784 b6f6f3c8 13ecc
b6f9df44 14784 b6f6f3c8 14784 b6f6f3c8 13d88 b6f9ea70 13d88 b6f9ea70 13c68 b6f99484
14628 b6f994b4 1485c b6fa0174 1452c b6faa2c4 14094 b6fabcb0 142b0
b6fab754 10104 10128 105d0 10390 136a0 00 00 00 00 00 00 00 00
Note that the addresses (10104 10128 105d0 10390 136a0) in bold above correspond to:
10104 _start ( entry point )
10128 _ start_c
105d0 __libc_start_main
10390 __init_libc
136a0 memset
1) How the entry point can end up at the end of the traces?
But when I trace a tiny interval of the .text section, for example from 0x100e0 to 0x136ac, I receive correct traces.
00 10104 10128 105d0 10390 136a0 10338 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4
103c4 103c4 103c4 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8
103e8 103e8 103e8 103e8 103e8 10420 10468 10480 10464 10464 10464 10464 10464 10480 10464
10464 10464 10464 10464 10480 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464
10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464
10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10488
138b4 10490 10388 10498 1048c 10404 1049c 10590 105f8 10598 100d4 100a4 10008 1fff0010 1fff009c
105bc 10214 1023c 10198 105c4 105fc 102c4 102a0 10300 1361c 13658 10310 10270 102b8 10330 10650
10698 10810 13318 108c8 108e4 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 10820
10810 10868 13318 108c8 108e4 10920 10968 10980 109c0 10a0c 10a68 10b20 10b34 10ba4 10ba0 10bec
10d20 13468 134e4 106ec 1070c 10810 13318 108c8 108e4 108e0 108e0 108e0 108e0 108e0 108e0 108e0
108e0 108e0 108e0 ………………
These addresses correspond to:
10104 _start
10128 _ start_c
105d0 __libc_start_main
10390 __init_libc
136a0 memset
10338
103c4 Loop in __init_libc
…..
103e8 Loop in __init_libc
….
102c4 main
…
2) Is there a limitation for the traced address range ? The only difference between those traces is the addr_range value:
For tracing the whole .text section :
echo -n 0x100e0 0x15140 > $PTM_CPU_0/addr_range
For tracing a tiny interval in the .text section
echo -n 0x100e0 0x136ac > $PTM_CPU_0/addr_range
If there is no limitation, what can explain this behaviour? A wrong configuration of the Coresight Components?
Kind Regards,
Mounir NASR ALLAH
Dear Mathieu,
I will like to clarify more on the `mode` file found in the mgmt of one of the ETM drivers.
The following is from the Documentations found in Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
What: /sys/bus/coresight/devices/<memory_map>.etm/mode
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Description: (RW) Controls various modes supported by this ETM, for example
P0 instruction tracing, branch broadcast, cycle counting and
context ID tracing.
I am asking about the functionality of this file because I want to be able to see how my traces will differ when i change the mode.
I have tweaked different values in mode and I realized that if the value != 0, it will not trace my program instruction addresses. I will only retrieve instruction addresses from kernel symbols (CPU_do_idle is found to be the specific instruction delivered by the CPU)
This is the snippet of the decoded trace using ptm2human ( I am also trying to figure if the decoder is indeed decoding the correct instructions from the trace dumps):
Context - Context ID = 0x0,
VMID = 0x0,
Address - Instruction address 0xffffff800895af78, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff8008161594, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800898b3c0, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800898b3c4, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff80081615c8, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800895af80, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800895b024, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff80081260e0, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800855cbd0, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800855cbf4, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800855cbec, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff8008126104, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800855cbd0, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800855cbf4, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800855cbec, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800812611c, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800895b030, Instruction set Aarch32 (Thumb)
Address - Instruction address 0xffffff800895b054, Instruction set Aarch32 (Thumb)
Exception - exception type IRQ, address 0xffffff800895b054
I will also upload the decoded trace dumps of the above (mode manipulated dump) in ed002000_mode.log
On another topic, I find it extremely amusing that I am able to trace my simple program. However,
according to the ETM options implemented, it should not be tracing any LDR/STR/conditional instructions yet
I have found the decoded traces to only be tracing LDR and STR. I have attached the source code of my math program and both the decoded (ec036000.etf.log) and the trace dump (ec036000.etf.bin). To make viewing of
the instructions better, please look at ec036000.etf_addr.log. A snippet of the decoded dump is found here:
Address - Instruction address 0x0000ffbefe7fc400, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555ba4, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bac, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bb4, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bbc, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bc4, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bcc, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bd4, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bdc, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555be4, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bec, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bf4, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555bfc, Instruction set Aarch32 (Thumb)
Address - Instruction address 0x0000005555555c04, Instruction set Aarch32 (Thumb)
I am using gdb to compare the program instruction addresses against the trace instruction addresses.
I have also deactivated ASLR to ensure that the values are always comparable. A snippet
of the instructions of my program using gdb is attached below:
|0x5555555b9c <main+500> add x8, x8, x10
|0x5555555ba0 <main+504> ldr x8, [x8]
|0x5555555ba4 <main+508> ldr x10, [sp,#144]
|0x5555555ba8 <main+512> and x10, x10, x13
|0x5555555bac <main+516> lsl x10, x12, x10
|0x5555555bb0 <main+520> and x8, x8, x10
|0x5555555bb4 <main+524> cmp x8, x9
|0x5555555bb8 <main+528> cset w15, ne
|0x5555555bbc <main+532> orr w16, wzr, #0x1
|0x5555555bc0 <main+536> and w15, w15, w16
|0x5555555bc4 <main+540> str w15, [sp,#20]
|0x5555555bc8 <main+544> b 0x5555555bd4 <main+556>
|0x5555555bcc <main+548> mov w8, #0x0 // #0
|0x5555555bd0 <main+552> str w8, [sp,#20]
|0x5555555bd4 <main+556> ldr w8, [sp,#20]
|0x5555555bd8 <main+560> str w8, [sp,#140]
|0x5555555bdc <main+564> ldr w8, [sp,#140]
|0x5555555be0 <main+568> cbnz w8, 0x5555555be8 <main+576>
|0x5555555be4 <main+572> b 0x5555555c80 <main+728>
|0x5555555be8 <main+576> orr x0, xzr, #0x10
|0x5555555bec <main+580> orr w3, wzr, #0x4
|0x5555555bf0 <main+584> ldur w2, [x29,#-40]
|0x5555555bf4 <main+588> ldr x8, [sp,#80]
|0x5555555bf8 <main+592> str x0, [sp,#8]
|0x5555555bfc <main+596> mov x0, x8
|0x5555555c00 <main+600> ldr x1, [sp,#72]
|0x5555555c04 <main+604> bl 0x55555558d0 <fprintf@plt>
The following are the trcidr values of my ETM:
trcidr0: 0x28000ea1
trcidr1: 0x4100f404
trcidr2: 0x488
trcidr3: 0xd7b00004
trcidr4: 0x11170004
trcidr5: 0x28c7081e
trcidr8: 0x0
trcidr9: 0x0
trcidr10: 0x0
trcidr11: 0x0
trcidr12: 0x0
trcidr13: 0x0
Hope I have provided sufficient information. Please advise!
Yours Sincerely,
Jeremy
This email may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are notified that any use, dissemination, distribution, or copying of this email, or any attachment, is strictly prohibited. Please delete the email immediately and inform the sender. Thank You
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
From: Wojciech Zmuda <wzmuda(a)n7space.com>
This patchset adds time notion to perf instruction and branch samples to allow
coarse time measurement of code blocks execution.
The simplest verification is visibility of the time field in 'perf script' output:
root@zynq:~# perf record -e cs_etm/timestamp,(a)fe970000.etr/u -a sleep 1
Couldn't synthesize bpf events.
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.262 MB perf.data ]
root@zynq:~# perf script --ns -F cpu,comm,time
perf [002] 9546.053455325:
perf [002] 9546.053455340:
perf [002] 9546.053455344:
(...)
sleep [003] 9546.060163742:
sleep [003] 9546.060163754:
sleep [003] 9546.060163766:
(...)
ntpd [001] 9546.389083194:
ntpd [001] 9546.389083400:
ntpd [001] 9546.389086319:
(...)
The step above works only if trace has been collected in CPU-wide mode because of some
perf event flags mismatch I'm working on fixing.
In general, timestamps in subsequent samples are monotonically increasing. Exceptions are:
- discontinuities in trace. From my understanding, we can't timestamp discontinuities
reasonably, since after decoder synchronizes back after trace loss, it needs to wait for
another timestamp packet. Thus, time value of such samples stays at 0x0.
- cases when a lot of non-branching instructions is executed between two subsequent timestamps.
Since we use approximation of timestamps for subsequent samples by increasing the timestamp
value by instruction count, it is possible that we go past the value of the next hardware
timestamp.
Another way to access these values is to use the perf script engine, which I used for validation
of the feature. The script below calculates timestamp differences of two consecutive branches
sharing the same branch address. This is a simple example of execution time fluctuation detector.
from __future__ import print_function
import os
import sys
sys.path.append(os.environ['PERF_EXEC_PATH'] + \
'/scripts/python/Perf-Trace-Util/lib/Perf/Trace')
from perf_trace_context import *
target_start_addr = int('4005e4', 16) # 0x4005e4 is func() from listing below
branch = dict()
branch['from'] = 0
branches = []
def process_event(s):
global branch
global branches
sample = s['sample']
branch['cpu'] = sample['cpu']
if not branch['from']:
branch['from'] = sample['addr']
branch['ts'] = sample['time']
return
branch['to'] = sample['ip']
if not branch['to']:
branch['from'] = 0
branch['ts'] = 0
return
if branch['from'] and branch['to']:
branches.append(branch.copy())
branch['from'] = 0
return
def trace_end():
global branches
count = 0
timestamp_start = 0
print("Got {0} samples:".format(len(branches)))
for b in branches:
if b['from'] == target_start_addr:
if not timestamp_start:
timestamp_start = b['ts']
continue
print("[{0}]: ts diff = 0x{1:x} - 0x{2:x} = {3:d}".format(count,
b['ts'], timestamp_start, b['ts'] - timestamp_start))
count = count + 1
timestamp_start = b['ts']
The following function was traced:
static int func(int cnt)
{
volatile int x = 0;
static int i;
x += cnt + 0xdeadbeefcafeb00b;
(...) /* repeats ~100 times */
if (i++ % 3 == 0) // Every third execution is longer
usleep(1000);
return x;
}
root@zynq:~# perf record -m,16K -e cs_etm/timestamp,(a)fe970000.etr/u \
--filter 'filter func @./program \
--per-thread ./program
Couldn't synthesize bpf events.
CTRL+C me when you find appropriate.
^C[ perf record: Woken up 12 times to write data ]
[ perf record: Captured and wrote 0.135 MB perf.data ]
root@zynq:~# perf script -s exectime.py
Got 2469 samples:
[0]: ts diff = 0x92f2752e512 - 0x92f274a7ae9 = 551465
[1]: ts diff = 0x92f2752e694 - 0x92f2752e512 = 386
[2]: ts diff = 0x92f2752e817 - 0x92f2752e694 = 387
[3]: ts diff = 0x92f275bef12 - 0x92f2752e817 = 591611
[4]: ts diff = 0x92f275bf093 - 0x92f275bef12 = 385
[5]: ts diff = 0x92f275bf211 - 0x92f275bf093 = 382
[6]: ts diff = 0x92f276451d7 - 0x92f275bf211 = 548806
[7]: ts diff = 0x92f2764535a - 0x92f276451d7 = 387
[8]: ts diff = 0x92f276454d7 - 0x92f2764535a = 381
[9]: ts diff = 0x92f276cb256 - 0x92f276454d7 = 548223
[10]: ts diff = 0x92f276cb3d9 - 0x92f276cb256 = 387
[11]: ts diff = 0x92f276cb556 - 0x92f276cb3d9 = 381
(...)
At the listing above it is visible that every third execution of the function lasted longer
than the other two. It is a naive example and could be enhanced to point to the area that
caused the disruption by examining events 'in the middle' of the traced code range.
Applies cleanly on Mathieu's 5.1-rc3-cpu-wide-v3 branch.
Changes for V3:
- fix checkpatch warnings
- don't timestamp discontinuity packets with hardware timestamp, as it is
for range packets only
- fix timestamping packets on full queue in per-thread mode
- simplify code in timestamping last branch samples before discontinuity
and in timestamping pending packets
Changes for V2:
- move packet timestamping logic to decoder. Front end only uses this information
to timestamp samples (as suggested by Mathieu).
- leave original behaviour of CPU-wide mode, where decoder is stopped
and front end is triggered about pending queue with timestamp packet.
At the same time, always adjust next and current timestamp in both CPU-wide
and per-thread modes (as suggested by Mathieu).
- when timestamp packet is encountered, timestamp range and discontinuity packets
waiting in the queue, that are not yet consumed by the front end (as suggested by Mathieu).
- don't timestamp exceptions, since they are not turned into branch nor instruction
samples.
- fix timestamping of the last branch sample before discontinuity appears (as suggested by Leo).
Wojciech Zmuda (1):
perf cs-etm: Set time value for samples
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 70 ++++++++++++++++++-------
tools/perf/util/cs-etm.c | 3 ++
tools/perf/util/cs-etm.h | 1 +
3 files changed, 55 insertions(+), 19 deletions(-)
--
2.11.0
Arm and arm64 architecture reserve some memory regions prior to the
symbol '_stext' and these memory regions later will be used by device
module and BPF jit. The current code misses to consider these memory
regions thus any address in the regions will be taken as user space
mode, but perf cannot find the corresponding dso with the wrong CPU
mode so we misses to generate samples for device module and BPF
related trace data.
This patch parse the link scripts to get the memory size prior to start
address and reduce this size from 'etmq->etm->kernel_start', then can
get a fixed up kernel start address which contain memory regions for
device module and BPF. Finally, cs_etm__cpu_mode() can return right
mode for these memory regions and perf can successfully generate
samples.
The reason for parsing the link scripts is Arm architecture changes text
offset dependent on different platforms, which define multiple text
offsets in $kernel/arch/arm/Makefile. This offset is decided when build
kernel and the final value is extended in the link script, so we can
extract the used value from the link script. We use the same way to
parse arm64 link script as well. If fail to find the link script, the
pre start memory size is assumed as zero, in this case it has no any
change caused with this patch.
Below is detailed info for testing this patch:
- Build LLVM/Clang 8.0 or later version;
- Configure perf with ~/.perfconfig:
root@debian:~# cat ~/.perfconfig
# this file is auto-generated.
[llvm]
clang-path = /mnt/build/llvm-build/build/install/bin/clang
kbuild-dir = /mnt/linux-kernel/linux-cs-dev/
clang-opt = "-DLINUX_VERSION_CODE=0x50200 -g"
dump-obj = true
[trace]
show_zeros = yes
show_duration = no
no_inherit = yes
show_timestamp = no
show_arg_names = no
args_alignment = 40
show_prefix = yes
- Run 'perf trace' command with eBPF event:
root@debian:~# perf trace -e string \
-e $kernel/tools/perf/examples/bpf/augmented_raw_syscalls.c
- Read eBPF program memory mapping in kernel:
root@debian:~# echo 1 > /proc/sys/net/core/bpf_jit_kallsyms
root@debian:~# cat /proc/kallsyms | grep -E "bpf_prog_.+_sys_[enter|exit]"
ffff000000086a84 t bpf_prog_f173133dc38ccf87_sys_enter [bpf]
ffff000000088618 t bpf_prog_c1bd85c092d6e4aa_sys_exit [bpf]
- Launch any program which accesses file system frequently so can hit
the system calls trace flow with eBPF event;
- Capture CoreSight trace data with filtering eBPF program:
root@debian:~# perf record -e cs_etm/(a)20070000.etr/ \
--filter 'filter 0xffff000000086a84/0x800' -a sleep 5s
- Annotate for symbol 'bpf_prog_f173133dc38ccf87_sys_enter':
root@debian:~# perf report
Then select 'branches' samples and press 'a' to annotate symbol
'bpf_prog_f173133dc38ccf87_sys_enter', press 'P' to print to the
bpf_prog_f173133dc38ccf87_sys_enter.annotation file:
root@debian:~# cat bpf_prog_f173133dc38ccf87_sys_enter.annotation
bpf_prog_f173133dc38ccf87_sys_enter() bpf_prog_f173133dc38ccf87_sys_enter
Event: branches
Percent int sys_enter(struct syscall_enter_args *args)
stp x29, x30, [sp, #-16]!
int key = 0;
mov x29, sp
augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);
stp x19, x20, [sp, #-16]!
augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);
stp x21, x22, [sp, #-16]!
stp x25, x26, [sp, #-16]!
return bpf_get_current_pid_tgid();
mov x25, sp
return bpf_get_current_pid_tgid();
mov x26, #0x0 // #0
sub sp, sp, #0x10
return bpf_map_lookup_elem(pids, &pid) != NULL;
add x19, x0, #0x0
mov x0, #0x0 // #0
mov x10, #0xfffffffffffffff8 // #-8
if (pid_filter__has(&pids_filtered, getpid()))
str w0, [x25, x10]
probe_read(&augmented_args->args, sizeof(augmented_args->args), args);
add x1, x25, #0x0
probe_read(&augmented_args->args, sizeof(augmented_args->args), args);
mov x10, #0xfffffffffffffff8 // #-8
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
add x1, x1, x10
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
mov x0, #0xffff8009ffffffff // #-140694538682369
movk x0, #0x6698, lsl #16
movk x0, #0x3e00
mov x10, #0xffffffffffff1040 // #-61376
if (syscall == NULL || !syscall->enabled)
movk x10, #0x1023, lsl #16
if (syscall == NULL || !syscall->enabled)
movk x10, #0x0, lsl #32
loop_iter_first()
3.69 → blr bpf_prog_f173133dc38ccf87_sys_enter
loop_iter_first()
add x7, x0, #0x0
loop_iter_first()
add x20, x7, #0x0
int size = probe_read_str(&augmented_filename->value, filename_len, filename_arg);
mov x0, #0x1 // #1
[...]
Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose(a)arm.com>
Cc: coresight(a)lists.linaro.org
Cc: linux-arm-kernel(a)lists.infradead.org
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
---
tools/perf/Makefile.config | 24 ++++++++++++++++++++++++
tools/perf/util/cs-etm.c | 26 +++++++++++++++++++++++++-
2 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 51dd00f65709..4776c2c1fb6d 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -418,6 +418,30 @@ ifdef CORESIGHT
endif
LDFLAGS += $(LIBOPENCSD_LDFLAGS)
EXTLIBS += $(OPENCSDLIBS)
+ ifneq ($(wildcard $(srctree)/arch/arm64/kernel/vmlinux.lds),)
+ # Extract info from lds:
+ # . = ((((((((0xffffffffffffffff)) - (((1)) << (48)) + 1) + (0)) + (0x08000000))) + (0x08000000))) + 0x00080000;
+ # ARM64_PRE_START_SIZE := (0x08000000 + 0x08000000 + 0x00080000)
+ ARM64_PRE_START_SIZE := $(shell egrep ' \. \= \({8}0x[0-9a-fA-F]+\){2}' \
+ $(srctree)/arch/arm64/kernel/vmlinux.lds | \
+ sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
+ awk -F' ' '{print "("$$6 "+" $$7 "+" $$8")"}' 2>/dev/null)
+ else
+ ARM64_PRE_START_SIZE := 0
+ endif
+ CFLAGS += -DARM64_PRE_START_SIZE="$(ARM64_PRE_START_SIZE)"
+ ifneq ($(wildcard $(srctree)/arch/arm/kernel/vmlinux.lds),)
+ # Extract info from lds:
+ # . = ((0xC0000000)) + 0x00208000;
+ # ARM_PRE_START_SIZE := 0x00208000
+ ARM_PRE_START_SIZE := $(shell egrep ' \. \= \({2}0x[0-9a-fA-F]+\){2}' \
+ $(srctree)/arch/arm/kernel/vmlinux.lds | \
+ sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
+ awk -F' ' '{print "("$$2")"}' 2>/dev/null)
+ else
+ ARM_PRE_START_SIZE := 0
+ endif
+ CFLAGS += -DARM_PRE_START_SIZE="$(ARM_PRE_START_SIZE)"
$(call detected,CONFIG_LIBOPENCSD)
ifdef CSTRACE_RAW
CFLAGS += -DCS_DEBUG_RAW
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 0c7776b51045..ae831f836c70 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -613,10 +613,34 @@ static void cs_etm__free(struct perf_session *session)
static u8 cs_etm__cpu_mode(struct cs_etm_queue *etmq, u64 address)
{
struct machine *machine;
+ u64 fixup_kernel_start = 0;
+ const char *arch;
machine = etmq->etm->machine;
+ arch = perf_env__arch(machine->env);
- if (address >= etmq->etm->kernel_start) {
+ /*
+ * Since arm and arm64 specify some memory regions prior to
+ * 'kernel_start', kernel addresses can be less than 'kernel_start'.
+ *
+ * For arm architecture, the 16MB virtual memory space prior to
+ * 'kernel_start' is allocated to device modules, a PMD table if
+ * CONFIG_HIGHMEM is enabled and a PGD table.
+ *
+ * For arm64 architecture, the root PGD table, device module memory
+ * region and BPF jit region are prior to 'kernel_start'.
+ *
+ * To reflect the complete kernel address space, compensate these
+ * pre-defined regions for kernel start address.
+ */
+ if (!strcmp(arch, "arm64"))
+ fixup_kernel_start = etmq->etm->kernel_start -
+ ARM64_PRE_START_SIZE;
+ else if (!strcmp(arch, "arm"))
+ fixup_kernel_start = etmq->etm->kernel_start -
+ ARM_PRE_START_SIZE;
+
+ if (address >= fixup_kernel_start) {
if (machine__is_host(machine))
return PERF_RECORD_MISC_KERNEL;
else
--
2.17.1
Arm and arm64 architecture reserve some memory regions prior to the
symbol '_stext' and these memory regions later will be used by device
module and BPF jit. The current code misses to consider these memory
regions thus any address in the regions will be taken as user space
mode, but perf cannot find the corresponding dso with the wrong CPU
mode so we misses to generate samples for device module and BPF
related trace data.
This patch parse the link scripts to get the memory size prior to start
address and reduce this size from 'etmq->etm->kernel_start', then can
get a fixed up kernel start address which contain memory regions for
device module and BPF. Finally, cs_etm__cpu_mode() can return right
mode for these memory regions and perf can successfully generate
samples.
The reason for parsing the link scripts is Arm architecture changes text
offset dependent on different platforms, which define multiple text
offsets in $kernel/arch/arm/Makefile. This offset is decided when build
kernel and the final value is extended in the link script, so we can
extract the used value from the link script. We use the same way to
parse arm64 link script as well. If fail to find the link script, the
pre start memory size is assumed as zero, in this case it has no any
change caused with this patch.
Below is detailed info for testing this patch:
- Build LLVM/Clang 8.0 or later version;
- Configure perf with ~/.perfconfig:
root@debian:~# cat ~/.perfconfig
# this file is auto-generated.
[llvm]
clang-path = /mnt/build/llvm-build/build/install/bin/clang
kbuild-dir = /mnt/linux-kernel/linux-cs-dev/
clang-opt = "-g"
dump-obj = true
[trace]
show_zeros = yes
show_duration = no
no_inherit = yes
show_timestamp = no
show_arg_names = no
args_alignment = 40
show_prefix = yes
- Run 'perf trace' command with eBPF event:
root@debian:~# perf trace -e string \
-e $kernel/tools/perf/examples/bpf/augmented_raw_syscalls.c
- Read eBPF program memory mapping in kernel:
root@debian:~# echo 1 > /proc/sys/net/core/bpf_jit_kallsyms
root@debian:~# cat /proc/kallsyms | grep -E "bpf_prog_.+_sys_[enter|exit]"
ffff000000086a84 t bpf_prog_f173133dc38ccf87_sys_enter [bpf]
ffff000000088618 t bpf_prog_c1bd85c092d6e4aa_sys_exit [bpf]
- Launch any program which accesses file system frequently so can hit
the system calls trace flow with eBPF event;
- Capture CoreSight trace data with filtering eBPF program:
root@debian:~# perf record -e cs_etm/(a)20070000.etr/ \
--filter 'filter 0xffff000000086a84/0x800' -a sleep 5s
- Annotate for symbol 'bpf_prog_f173133dc38ccf87_sys_enter':
root@debian:~# perf report
Then select 'branches' samples and press 'a' to annotate symbol
'bpf_prog_f173133dc38ccf87_sys_enter', press 'P' to print to the
bpf_prog_f173133dc38ccf87_sys_enter.annotation file:
root@debian:~# cat bpf_prog_f173133dc38ccf87_sys_enter.annotation
bpf_prog_f173133dc38ccf87_sys_enter() bpf_prog_f173133dc38ccf87_sys_enter
Event: branches
Percent int sys_enter(struct syscall_enter_args *args)
stp x29, x30, [sp, #-16]!
int key = 0;
mov x29, sp
augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);
stp x19, x20, [sp, #-16]!
augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);
stp x21, x22, [sp, #-16]!
stp x25, x26, [sp, #-16]!
return bpf_get_current_pid_tgid();
mov x25, sp
return bpf_get_current_pid_tgid();
mov x26, #0x0 // #0
sub sp, sp, #0x10
return bpf_map_lookup_elem(pids, &pid) != NULL;
add x19, x0, #0x0
mov x0, #0x0 // #0
mov x10, #0xfffffffffffffff8 // #-8
if (pid_filter__has(&pids_filtered, getpid()))
str w0, [x25, x10]
probe_read(&augmented_args->args, sizeof(augmented_args->args), args);
add x1, x25, #0x0
probe_read(&augmented_args->args, sizeof(augmented_args->args), args);
mov x10, #0xfffffffffffffff8 // #-8
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
add x1, x1, x10
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
mov x0, #0xffff8009ffffffff // #-140694538682369
movk x0, #0x6698, lsl #16
movk x0, #0x3e00
mov x10, #0xffffffffffff1040 // #-61376
if (syscall == NULL || !syscall->enabled)
movk x10, #0x1023, lsl #16
if (syscall == NULL || !syscall->enabled)
movk x10, #0x0, lsl #32
loop_iter_first()
3.69 → blr bpf_prog_f173133dc38ccf87_sys_enter
loop_iter_first()
add x7, x0, #0x0
loop_iter_first()
add x20, x7, #0x0
int size = probe_read_str(&augmented_filename->value, filename_len, filename_arg);
mov x0, #0x1 // #1
[...]
Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose(a)arm.com>
Cc: coresight(a)lists.linaro.org
Cc: linux-arm-kernel(a)lists.infradead.org
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
---
tools/perf/Makefile.config | 20 ++++++++++++++++++++
tools/perf/util/cs-etm.c | 19 ++++++++++++++++++-
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 51dd00f65709..cf5906d667aa 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -418,6 +418,26 @@ ifdef CORESIGHT
endif
LDFLAGS += $(LIBOPENCSD_LDFLAGS)
EXTLIBS += $(OPENCSDLIBS)
+ ARM_PRE_START_SIZE := 0
+ ifeq ($(SRCARCH),arm64)
+ # Extract info from lds:
+ # . = ((((((((0xffffffffffffffff)) - (((1)) << (48)) + 1) + (0)) + (0x08000000))) + (0x08000000))) + 0x00080000;
+ # ARM_PRE_START_SIZE := (0x08000000 + 0x08000000 + 0x00080000)
+ ARM_PRE_START_SIZE := $(shell egrep ' \. \= \({8}0x[0-9a-fA-F]+\){2}' \
+ $(srctree)/arch/arm64/kernel/vmlinux.lds | \
+ sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
+ awk -F' ' '{print "("$$6 "+" $$7 "+" $$8")"}' 2>/dev/null)
+ endif
+ ifeq ($(SRCARCH),arm)
+ # Extract info from lds:
+ # . = ((0xC0000000)) + 0x00208000;
+ # ARM_PRE_START_SIZE := 0x00208000
+ ARM_PRE_START_SIZE := $(shell egrep ' \. \= \({2}0x[0-9a-fA-F]+\){2}' \
+ $(srctree)/arch/arm/kernel/vmlinux.lds | \
+ sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
+ awk -F' ' '{print "("$$2")"}' 2>/dev/null)
+ endif
+ CFLAGS += -DARM_PRE_START_SIZE="$(ARM_PRE_START_SIZE)"
$(call detected,CONFIG_LIBOPENCSD)
ifdef CSTRACE_RAW
CFLAGS += -DCS_DEBUG_RAW
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 0c7776b51045..5fa0be3a3904 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -613,10 +613,27 @@ static void cs_etm__free(struct perf_session *session)
static u8 cs_etm__cpu_mode(struct cs_etm_queue *etmq, u64 address)
{
struct machine *machine;
+ u64 fixup_kernel_start = 0;
machine = etmq->etm->machine;
- if (address >= etmq->etm->kernel_start) {
+ /*
+ * Since arm and arm64 specify some memory regions prior to
+ * 'kernel_start', kernel addresses can be less than 'kernel_start'.
+ *
+ * For arm architecture, the 16MB virtual memory space prior to
+ * 'kernel_start' is allocated to device modules, a PMD table if
+ * CONFIG_HIGHMEM is enabled and a PGD table.
+ *
+ * For arm64 architecture, the root PGD table, device module memory
+ * region and BPF jit region are prior to 'kernel_start'.
+ *
+ * To reflect the complete kernel address space, compensate these
+ * pre-defined regions for kernel start address.
+ */
+ fixup_kernel_start = etmq->etm->kernel_start - ARM_PRE_START_SIZE;
+
+ if (address >= fixup_kernel_start) {
if (machine__is_host(machine))
return PERF_RECORD_MISC_KERNEL;
else
--
2.17.1
Based on the following report from Smatch tool, make sure we have a
valid drvdata before we dereference it to find the real dev.
The patch 21d26b905c05: "coresight: etm: Clean up device specific
data" from May 22, 2019, leads to the following Smatch complaint:
./drivers/hwtracing/coresight/coresight-etm3x.c:460 etm_get_trace_id()
warn: variable dereferenced before check 'drvdata' (see line 458)
./drivers/hwtracing/coresight/coresight-etm3x.c
457 int trace_id = -1;
458 struct device *etm_dev = drvdata->csdev->dev.parent;
^^^^^^^^^
New dereference
459
460 if (!drvdata)
^^^^^^^^
Checked too late. Delete the check?
461 goto out;
462
Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Cc: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
---
drivers/hwtracing/coresight/coresight-etm3x.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index bed7291..225c298 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -455,11 +455,12 @@ int etm_get_trace_id(struct etm_drvdata *drvdata)
{
unsigned long flags;
int trace_id = -1;
- struct device *etm_dev = drvdata->csdev->dev.parent;
+ struct device *etm_dev;
if (!drvdata)
goto out;
+ etm_dev = drvdata->csdev->dev.parent;
if (!local_read(&drvdata->mode))
return drvdata->traceid;
--
2.7.4
(It's very urgent, please transfer this email to your CEO. Thanks)
This email is from China domain name registration center, which mainly deal with the domain name registration in China. On June 10, 2019, we received an application from Kaicheng Ltd requested "coresight" as their internet keyword and China (CN) domain names (coresight.cn, coresight.com.cn, coresight.net.cn, coresight.org.cn). But after checking it, we find this name conflict with your company name or trademark. In order to deal with this matter better, it's necessary to send email to you and confirm whether your company have connection with this Chinese company or not?
Best Regards
*************************************
Nick Liu | Service & Operations Manager
China Registry (Head Office) | 6012, Xingdi Building, No. 1698 Yishan Road, Shanghai 201103, China
Tel: +86-02164193517 | Fax: +86-02164198327 | Mob: +86-13816428671
Email: nick(a)chinaregistry.org.cn
Web: www.chinaregistry.org.cn
*************************************
This email contains privileged and confidential information intended for the addressee only. If you are not the intended recipient, please destroy this email and inform the sender immediately. We appreciate you respecting the confidentiality of this information by not disclosing or using the information in this email.
hi all,considering the big progress achieved in coresight drivers, perf, as well as opencsd, the prerequisites for making a move towards developing branch tracing in gdb for arm processors, based on etm are now available. Therefore I am publishing this request for comment, and looking forward for your feedback on this proposal.
Non intrusive execution recording for GDB using ARM CoreSight
Status of this Memo
This memo provides information for Linaro coresight and toolchain communities. Distribution of this memo is unlimited.
Abstract
A method of realizing execution recording in GDB in a non-intrusive way. This method is based on the use of CoreSight hardware tracing, available on ARM Cortex devices.
Table of Contents
1 Introduction 2 State of the art 3 Use cases 3.1 Self hosted debug monitor 3.2 Remote debug monitor 3.3 External debugger 4 Implementation needs 4.1 Self hosted debug monitor 4.2 Remote Debug monitor 4.3 External debugger 5 Remote protocol execution sequence 6 Remote protocol extensions 7 Solutions and alternatives 7.1 Scope definition 7.2 CoreSight infrastructure exposure to the user 7.3 Parameters needed for parsing traces
1. Introduction
CoreSight technology offers a toolset for tracing the execution of a program on a CPU, as well as routing the traces to an external trace port analyzer or storing it in a dedicated internal memory. Those traces do not affects system performance, and can be used as a record for program execution. GDB offers reverse debugging by recording program execution and storing it. GDB offers either full record or program flow (branch) record. Records can be replayed later-on for forwards or backwards debugging. This request for comments is about realizing GDB record and replay functionality using CoreSight technology. it presents typical use cases and discuss different alternatives for realizing above mentioned feature. 2. State of the art
GDB currently supports two execution recording variants: - full record: where registers as well as memory are recorded for each instruction. in this case GDB collects the registers as well as involved memory area after each instruction. currently this has no support for hardware accelerators - branch record: where only program flow is recorded. in this case GDB collects a list of linear execution called blocks. each branch will terminate previous block and start a new one. currently branch is implemented either without hardware acceleration or using Intel branch trace store "bts" and Intel processor trace "pt" hardware accelerator on supported cpus.
3. Use cases
Programs running on ARM processors can be be debugged in many configurations. three of them are selected in this RFC as base for discussion : 3.1. Self hosted debug monitor Those are systems where the debugger program runs on the same cpu as the debugged program and monitors it. user interacts with the debugging session on the target host itself. Linux gdb is an example of such systems. in such a system following setup is considered - Target: a process running on an ARM cortex A - Debugger: gnu gdb via ptrace API (arm-linux-gnueabihf-gdb)
+-----------------------------------+ | Target | | +------------+ | | +------+ | Coresight | | | | | | components:| | | | GDB |<--------->| | | | | | ^ | DWT, ETM, | | | +------+ | | ITM, TPIU | | | ^ | | TMC, ETB | | | | | +------------+ | +----|---------|--------------------+ | | | | arm-linux- | gnueabihf- | gdb | debug: ptrace trace: perf/CoreSight drivers
3.2. Remote debug monitor
Those are usually systems where the debugger program runs on the same cpu as the debugged program and monitors it. user interacts with the debugging session remotely from a PC Linux gdb is an example of such systems. in such a system following setup is considered - Target: a process running on an ARM cortex A - Gdb server: gnu gdbserver (arm-linux-gnueabihf-gdbserver) - Gdb client: gnu gdb (arm-linux-gnueabihf-gdb) - UI: eclipse with needed plugins, MI interface is used.
+--------------------------+ +---------------------------------------+ | Host | | Target | | | | +------------+ | | +-----+ +------+ | | +------+ | Coresight | | | | | | GDB | | | | GDB | | components:| | | | UI |<--->| |<--->|<--->|<--->| |<--------->| | | | | | ^ |Client| ^ | ^ | |Server| ^ | DWT, ETM, | | | +-----+ | +------+ | | | | +------+ | | ITM, TPIU | | | ^ | ^ | | | | ^ | | TMC, ETB | | | | | | | | | | | | +------------+ | +----|-----|-----|------|--+ | +--------|---------|--------------------+ | | | | | | | | | | | | | | Eclipse | arm-linux- | | arm-linux- | | gnueabihf- | TCP/IP gnueabihf- | | gdb | UART gdbserver | GDB MI GDB remote debug: ptrace protocol trace: perf/CoreSight drivers
3.3. External debugger
Those are systems where an external debugger is used. It accesses the target using JTAG or SWD. Target is usually a bare metal embedded systems or systems with an rtos. as an example, following setup is considered: - Target: firmware running on ARM cortex M. - Debugger: external debug and trace device. - Gdb server: OpenOcd. - Gdb Client: arm-none-eabi-gdb. - UI: eclipse with needed plugins, MI interface is used.
+--------------------------------------+ +-------+ +-------------+ | Host | | dbggr | | Target | | | | | | | | +-----+ +------+ +------+ | | | | Coresight | | | | | GDB | | GDB | | | Debug | | components: | | | UI |<--->| |<--->| |<-->|<--->| + |<--->| | | | | ^ |Client| ^ |Server| | ^ | Trace | ^ | DWT, ETM, | | +-----+ | +------+ | +------+ | | | | | | ITM, TPIU | | ^ | ^ | ^ | | | | | | | | | | | | | | | | | | | | +----|-----|-----|------|-----|--------+ | +-------+ | +-------------+ | | | | | | | | | | | | | | Eclipse | arm-none- | OpenOcd | | | eabi-gdb | PyOcd | | | | | | GDB MI GDB remote Ethernet debug: JTAG/SWD protocol USB trace: Serial/Parallel
4. Implementation needs
4.1 Self hosted debug monitor
gdb : arm-linux-gnueabihf-gdb the interface defined in btrace.h for capturing and processing traces has to be implemented for arm CoreSight needed actions: - in btrace-common.h: add needed structures for capturing and handling etm traces - in linux-btrace.h: - add btrace_tinfo_etm - amend btrace_target_info - in linux-btrace.c: change following functions to support etm traces - linux_enable_btrace - linux_disable_btrace - linux_read_btrace - linux_btrace_conf - in arm-linux-nat.c:add an api to - configure btrace - enable btrace - disable btrace - read btrace - in btrace.c - btrace_add_pc btrace_fetch has to be implemented for Coresight this means using opencsd library to parse etms and then reconstruct executed instructions accordingly (btrace_compute_ftrace_1) - in record-btrace.c - add command for showing record btrace etm options - add command for starting tracing with CoreSight and its handler (cmd_record_btrace_etm_start) - adapt cmd_show_record_btrace_cpu ... perf: needed actions: - make sure that perf can start/stop tracing a process with its threads, collect etm traces and deliver them to the user
4.2 Remote Debug monitor
changes described in 7.1 are needed. in addition, and to support remote protocol following changes are needed gdb server: arm-linux-gnueabihf-gdbserver needed actions: - in linux-low - linux_low_read_btrace: add support for etm traces formatting. - linux_low_btrace_conf: :add support for etm configuration formatting. gdb client: arm-linux-gnueabihf-gdb needed actions: - in remote.c - adapt enable_btrace - adapt disable_btrace - in btrace.c - parse_xml_btrace: update btrace.dtd [2] and related data structures btrace_xxx - parse_xml_btrace_conf: update btrace-conf.dtd [3] and related data structures btrace_conf_xxx - extend Remote protocol handling to support coresight etm traces UI: eclipse needed actions make sure that the plugin for recoding execution and replaying it is coping well in case of arm-linux
Remote protocol needs to be extended by -1- Adding Qbtrace:CoreSight (or etm) to start collecting etm traces -2- Amending 'Branch Trace Format' xml specification to consider etm traces transfer -3- Amending 'Branch Trace Configuration Format' xml specification to consider parameters needed for etm
4.3 External debugger
changes described in 4.2 are needed. in addition, and to support tracing a remote dealing with an external debugger (bare metal embedded system) following changes are needed gdb server: OpenOcd needed actions: - rework etm driver to make it up to date. - add a driver for configuring trace interconnect IPs - rework the driver for TPIU. - integrate support for a Trace port analyzer. -Extend remote protocol implementation to support recording Coresight infrastructure of the SoC is to be set in OpenOcd through configuration files. Parameters that are not relevant for gdb are also specified in configuration files (trace sink, trace protocol, port size, trace synch frequency, cycle accurate tracing etc ...) gdb client: arm-none-eabi-gdb needed actions: - extend Remote protocol to support coresight etm traces - integrate etm trace parsing library - interface the parser to record_btrace_target Remote protocol needs -in addition to 4.2- to be extended by - Adding Qbtrace-conf:CoreSight:core=value to support multicore SoC - Adding btrace-conf:CoreSight:id=value to support demultiplexing multiple trace sources - Adding Qbtrace-conf:CoreSight:filter:context=value to support filtering traces belonging to a given process/thread - Adding Qbtrace-conf:CoreSight:filter:start-address=value and Qbtrace-conf:CoreSight:filter:end-address=value to support filtering traces for given functions/blocks/lib - Adding Qbtrace-conf:CoreSight:trigger:on-address=value and Qbtrace-conf:CoreSight:trigger:off-address=value to support triggering tracing or stop tracing if a certain function/block/lib is executed alternatively some of configurations related to filtering and triggering can be delegated to the GDB server. UI: eclipse test and verify that existing plugins cope well with gdb extensions
5. Remote protocol execution sequence
gdb and gdbserver are communicating using the gdb remote protocol. on a semantic level a tracing session runs though following sequence (1) gdb client queries gdb server support for branch trace (2) gdb server answers with - qXfer:btrace:read - qXfer:btrace-conf:read - Qbtrace:off - Qbtrace:CoreSight - Qbtrace-conf:CoreSight:xxx where xxx is the parameter name (3) gdb client sends command to let start emitting and collecting traces (Qbtrace:CoreSight) (4) gdb server executes the commands (5) gdb client sends command to stop emitting and collecting traces (Qbtrace:off) (6) gdb server exectues the command (7) gdb client sends command to get collected traces from trace sink (qXfer:btrace:read:annex:offset,length) (8) gdb server executes the command and sends back collected traces (9) gdb client parses the traces and reconstructs target states
6. Remote protocol extensions
the remote protocol needs be extended with following primitives to support CoreSight tracing - start tracing and traces capture using CoreSight (Qbtrace:CoreSight) the remote protocol can be extended with following primitives to take advantages of etm functionalities. - select the core to trace on in the case of a multicore system gdb client sends command to select the core to trace (Qbtrace-conf:CoreSight:core=value) - set the trace id for the traces gdb client sends command to set trace id (Qbtrace-conf:CoreSight:id=value) - select the context to trace gdb client sends command to select the context to trace (Qbtrace-conf:CoreSight:filter:context=value) - select the address range to trace gdb client sends command to select the address range to trace (Qbtrace-conf:CoreSight:filter:start-address=value) (Qbtrace-conf:CoreSight:filter:end-address=value) - set triggers for starting and stopping tracing gdb client sends command to select the address to trigger tracing (Qbtrace-conf:CoreSight:trigger:on-address=value) (Qbtrace-conf:CoreSight:trigger:off-address=value)
7. alternatives and discussions
7.1. Scope definition
Coresight ETM IP comes in many versions and many implementations. According to its capabilities, it can trace instructions only or instructions and involved data/data address. All ETMs variants support instructions tracing and can therefore be used for for branch tracing.
7.2. CoreSight infrastructure exposure to the user
it is here about assigning the responsibility of configuring Coresight infrastructure to generate and route traces. two alternatives are possible: - coresight infrastructure exposed to gdb client (and UI): in this alternative the user or the UI is responsible for configuring coresight IPs in the SoC, by accessing their registers directly or via coresigh driver. Remote protocol is used to configure trace sink (ETB or TPA) to start/stop collecting traces - coresight infrastructure is not exposed outside of gdbserver. in this case high level commands can be provided by gdbserver remote protocol to setup and configure coresight IPs in the SoC. My recommendation is to extend remote protocol to provide high level commands to setup and configure coresight IPs in the SoC, or to use a different channel to pass configuration parameters to gdb server
7.3. parameters needed for parsing traces Some configuration parameters like etm version, trace id ... (content of registers ETMCR, ETMIDR, ETMCCER, ETMTRACEIDR) are needed for extracting and parsing etm trace, those parameters needs to be exchanged between gdb server and client. following alternatives are possible: - extend the remote protocol to get those params with explicit queries - add them to the content of the response to qXfer:btrace-conf:read - add them to the content of the response to qXfer:btrace:read
Best RegardsZied Guermazi
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Suzuki noticed that this should be more useful in a generic header, and
after looking I noticed we have it already in our copy of
include/linux/bits.h in tools/include, so just use it, test built on
x86-64 and ubuntu 19.04 with:
perfbuilder@46646c9e848e:/$ aarch64-linux-gnu-gcc --version |& head -1
aarch64-linux-gnu-gcc (Ubuntu/Linaro 8.3.0-6ubuntu1) 8.3.0
perfbuilder@46646c9e848e:/$
Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Link: https://lkml.kernel.org/r/68c1c548-33cd-31e8-100d-7ffad008c7b2@arm.com
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Leo Yan <leo.yan(a)linaro.org>
Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: coresight(a)lists.linaro.org
Cc: linux-arm-kernel(a)lists.infradead.org,
Link: https://lkml.kernel.org/n/tip-69pd3mqvxdlh2shddsc7yhyv@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
---
tools/perf/util/cs-etm.h | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
index 33b57e748c3d..bc848fd095f4 100644
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -9,6 +9,7 @@
#include "util/event.h"
#include "util/session.h"
+#include <linux/bits.h>
/* Versionning header in case things need tro change in the future. That way
* decoding of old snapshot is still possible.
@@ -161,16 +162,6 @@ struct cs_etm_packet_queue {
#define CS_ETM_INVAL_ADDR 0xdeadbeefdeadbeefUL
-/*
- * Create a contiguous bitmask starting at bit position @l and ending at
- * position @h. For example
- * GENMASK_ULL(39, 21) gives us the 64bit vector 0x000000ffffe00000.
- *
- * Carbon copy of implementation found in $KERNEL/include/linux/bitops.h
- */
-#define GENMASK(h, l) \
- (((~0UL) - (1UL << (l)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (h))))
-
#define BMVAL(val, lsb, msb) ((val & GENMASK(msb, lsb)) >> lsb)
#define CS_ETM_HEADER_SIZE (CS_HEADER_VERSION_0_MAX * sizeof(u64))
--
2.20.1