Closed japaric closed 5 months ago
Figure how to feed debug info into the tool to get flame graphs with proper line information (instead of just PC addresses). This sounds tricky to me as I know nothing about using debuginfo without a debugger.
Thankfully this is utterly trivial. Run arm-none-gnueabi-addr2line -Cfi -e <binary>
, feed it addresses on stdin, get decoded info on stdout.
I started a debug tooling thread on users.rust-lang before finding this RFC.
There I wrote:
On the microcontroller we probably want Rust support for:
- TPIU configuration (multiplexes and encodes debug data)
- ITM (transfers application data)
- ETM (instruction-level tracing)
- DWT (profiling, breakpoints, watchpoints)
I see TPIU, ITM, DWT code in the
cortex-m
crate. I'll try to add anything appropriate I come up with there. I think ETM code should live there too. Perhaps it should be behind a feature flag, as the ARM v7-M architecture reference manual indicates ETM is optional.For profiling we would probably configure the peripherals with Rust, but then other tools probably do most/all of the host-side work.
orbuculum
'sorbstat
converts PC samples for KCachegrind (screenshots), which has a source code view annotated with time per line and call tree graph. Converting lines of PC samples for other tools should be very easy, including FlameGraph.
Lautherbach Trace32 is the de-facto tool everybody in the professional world use. Yes it is really expensive, I agree. Here an example of T32 on a Safety Critial ARM Cortex-4RF CPU in Lock-Step mode I use daily in lab. and it work seamless in Rust. (Perf Trace, Power Cons., Event, PMUs counters) Collecting ITM data or similar, without hw support (JTAG, ICD with up to 5GB of trace mem. and logic analyzer channels) it is not useful. It is just wrong data.
Disclaimer: I do not work for Lautherbach. There are few other professional tool (one from ARM) that are similar to T32.
Chip like XDS100, that you can find in low-cost boards, are low performance chip. Just to sell an evaluation boards. At the end what I want to say it that "tracing without assistance of a dedicated hw (JTAG/ICD) it is really hard or quite impossible".
Triage: itm-tools
is now a thing
First thing is to collect information about the ITM registers and the ITM frames related to the tracing functionality.
ARMv7-M Architecture Reference Manual (DDI 0403E.b) - Appendix D4 Debug ITM and DWT Packet Protocol
CoreSight Components Technical Reference Manual (DDI 0314H) - Chapter 12 Instrumentation Trace Macrocell
Extend the ITM API on the cortex-m crate to deal with setting up the tracing stuff.
I have been using OpenOCD / GDB to set the appropriate bits (see itm-tools
'
README), but adding a safe API to cortex-m
should be straightforward.
Extend the itm crate to handle parsing of ITM frames related to tracing.
PR https://github.com/rust-embedded/itm/pull/24 adds parsing support for all the ARMv7-M ITM packets.
Build a basic tool that grabs the ITM frames from a device (e.g. /dev/ttyUSB0) or a file (itm.dump) and just prints the decoded frames to stdout.
See itm-tools
' itm-decode
Start adding functionality like context switch counting, interrupt time measurement, and flame graphs
See itm-tools
' excevt
(exception event tracing) and pcsampl
(PC sampling).
Awesome!
Closing this as a part of the 2024 triage.
As of now, the charter of the WG is to focus on foundational crates and functionality, rather than develop solutions for all use cases. However, as of today there are the following existing solutions, and folks finding this issue are suggested to contribute to one of the following projects:
probe-rs
's "profile" command: https://github.com/probe-rs/probe-rs/blob/master/probe-rs-tools/src/bin/probe-rs/cmd/profile.rsIf you think this was closed incorrectly, please leave a comment and we can revisit this decision in the next weekly WG meeting on Matrix.
Update: 2019-01-20
See
itm-tools
In my last blog post I talked about the Instrumentation Trace Macrocell (ITM) peripheral as a mean to log data and/or debug messages from a microcontroller to a PC or some other host. However the ITM can be used to trace many other things like:
It can sample the Program Counter which can be mapped back to source code to produce flame graphs (where in the program is the processor spending most of its time?).
It can trace entries to and exits from exceptions and interrupts which you could use to count context switches and measure the time spent in interrupt context.
It can trace memory accesses to arbitrary (?) memory regions.
All this with timestamps accurate to the clock cycle.
I'm opening this issue to see if there are people interested in building a cross platform Rust tool that can collect this performance information and present in some way (text or graphs; it doesn't matter much how it's presented in the first versions) as I'm not sure how much time I can put into this myself.
Here's more or less what needs to be done:
There are two aspects to this tool: the register manipulation necessary on the device side, and the frame decoding and processing on the host side. So
ARMv7-M Architecture Reference Manual (DDI 0403E.b) - Appendix D4 Debug ITM and DWT Packet Protocol
CoreSight Components Technical Reference Manual (DDI 0314H) - Chapter 12 Instrumentation Trace Macrocell
Extend the ITM API on the
cortex-m
crate to deal with setting up the tracing stuff?[x] Extend the
itm
crate to handle parsing of ITM frames related to tracing.See https://github.com/rust-embedded/itm/pull/24
See
itm-tools
See
itm-tools
[ ] Figure how to feed debug info into the tool to get flame graphs with proper line information (instead of just PC addresses). This sounds tricky to me as I know nothing about using debuginfo without a debugger.
[ ] :tada: