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
Request for Comments June 2019
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
2 State of the art ...................................... 2
3 Use cases ............................................. 3
3.1 Self hosted debug monitor ........................... 3
3.2 Remote debug monitor................................. 4
3.3 External debugger ................................... 5
4 Implementation needs .................................. 6
4.1 Self hosted debug monitor ........................... 6
4.2 Remote Debug monitor................................. 7
4.3 External debugger ................................... 8
5 Remote protocol execution sequence .................... 9
6 Remote protocol extensions ............................ 10
7 Solutions and alternatives ............................ 11
7.1 Scope definition .................................... 11
7.2 CoreSight infrastructure exposure to the user ....... 11
7.3 Parameters needed for parsing traces ................ 11
Zied Guermazi [Page 1]
Non intrusive execution recording for GDB using ARM CoreSight June 2019
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.
Zied Guermazi [Page 2]
Non intrusive execution recording for GDB using ARM CoreSight June 2019
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
Zied Guermazi [Page 3]
Non intrusive execution recording for GDB using ARM CoreSight June 2019
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
Zied Guermazi [Page 4]
Non intrusive execution recording for GDB using ARM CoreSight June 2019
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
Zied Guermazi [Page 5]
Non intrusive execution recording for GDB using ARM CoreSight June 2019
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
Zied Guermazi [Page 6]
Non intrusive execution recording for GDB using ARM CoreSight June 2019
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
Zied Guermazi [Page 7]
Non intrusive execution recording for GDB using ARM CoreSight June 2019
4.3 External debugger
changes described in 7.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 7.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
Zied Guermazi [Page 8]
Non intrusive execution recording for GDB using ARM CoreSight June 2019
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
Zied Guermazi [Page 9]
Non intrusive execution recording for GDB using ARM CoreSight June 2019
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)
Zied Guermazi [Page 10]
Non intrusive execution recording for GDB using ARM CoreSight April 2019
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
Zied Guermazi [Page 11]
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
