probe-rs: probe-rs doesn't break on or step over macros

Describe the bug Breakpoints are not able to be set on lines that invoke macros. In addition, stepping to a line with a macro invocation fails, and execution resumes until the next breakpoint is hit.

To Reproduce Steps to reproduce the behavior:

Try setting a breakpoint on a macro invocation like defmt::error!()

Pause execution on a line before a macro
Try to step to next line

Stacktrace If I try setting a breakpoint on a macro line, I get:

WARNING: Cannot set breakpoint here. Try reducing `opt-level` in `Cargo.toml`, or choose a different source location: Other(No valid breakpoint information found for file: "/Users/ryan.butler/P/slimevr/rust/firmware/src/main.rs", line: 26, column: Some(1))

Desktop (please complete the following information):

macOS Monterey (12.5.1) (apple m1/arm64)

Additional context I am using an ESP32-C3 via the onboard usb JTAG peripheral (USB port is directly connected to the D+ and D- pins of the MCU)

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 15 (15 by maintainers)

Commits related to this issue

probe-rs doesn't break on or step over macros Fixes #1230 — committed to probe-rs/probe-rs by noppej 2 years ago
Merge #1327 1327: Fix unpredictable behaviour when breaking on, or stepping over macros. (#1230) r=Yatekii a=noppej Co-authored-by: JackN <noppej@hotmail.com> — committed to probe-rs/probe-rs by bors[bot] 2 years ago

Most upvoted comments

@TheButlah Are you able to validate #1327. I can no longer reproduce the problem on my own repo, or the one you linked above.

I don’t have access to my hardware rn as I’m on vacation. If I ever notice the issue again I’ll let you know.

TheButlah on Dec 14, 2022

It would make the experience much better if the step function could detect this beforehand, and then warn you that it would cause execution to be fully resumed instead of stepping.

This is what I’ve been aiming for in the code, but there are obviously some scenarios that escape detection. But your point is 100% valid 😃

noppej on Sep 19, 2022

@TheButlah This is running into a situation where the debug info doesn’t provide enough information to know where to set a breakpoint for that statement. The code to step correctly relies on knowing which is the next statement (there can be multiple statements on a single line in the source, and each statement is made up of multiple machine instructions which can be grouped into multiple execution sequences). When a single statement compiles into multiple machine instructions which belong to multiple execution sequences, then we exceed the current logic of probe-rs stepping capability (Open a VSCode Disassembly window at the line before the debug macro, and you will see how complex the execution sequence is for that single line of code).

I don’t believe this is unique to macros, but certainly the defmt macros are complex enough to trigger this limitation more frequently.

I will work on this, but it is a non-trivial fix, so in the mean time, I recommend you use breakpoints after the macros to make sure you can halt when expected.

noppej on Sep 19, 2022

BTW, the panic I am referring to occurs much later in the program, after the async executor has already been initalized and the tasks begin attempting IO. I have confirmed that if I were to set a breakpoint at line 29, then when the debugger fails to break at line 26, it will continue until line 29.

(updated) Link to my code in case its helpful for reproducing the error: https://github.com/SlimeVR/SlimeVR-Rust/blob/ca9810aab796f1a79295bf98ba3c491a0b867667/firmware/src/main.rs#L21

TheButlah on Sep 19, 2022