Stuck at 5.3 - gdb issue at break main - hangs on continue

[davelongdev]

I'm having a similar issue to (#7) at the moment . I'm on arch linux. I run

cargo embed --example init

from the 05-meet-your-software directory, which seems to work. Then I'm getting this, instead of what's indicated in the book.

% arm-none-eabi-gdb ../../../target/thumbv7em-none-eabihf/debug/examples/init
...
Reading symbols from ../../../target/thumbv7em-none-eabihf/debug/examples/init...
(gdb) target remote :1337
Remote debugging using :1337
cortex_m::asm::wfi ()
    at /home/dave/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cortex-m-0.7.7/src/asm.rs:56
56      }
(gdb) b main
Breakpoint 1 at 0x15c: file mdbook/src/05-meet-your-software/examples/init.rs, line 10.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
cortex_m::asm::wfi ()
    at /home/dave/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cortex-m-0.7.7/src/asm.rs:56
56      }
(gdb) quit
A debugging session is active.

        Inferior 1 [process 1] will be detached.

Quit anyway? (y or n) y
Detaching from program: /home/dave/rust-discovery-mb2/target/thumbv7em-none-eabihf/debug/examples/init, process 1
Ending remote debugging.
[Inferior 1 (process 1) detached]

It just hangs after continue, and I have to interrupt it.

I've been trying to trouble shoot the issue, but no luck so far. Any help would be appreciated. Thanks.

[davelongdev]

I just went through the setup in an ubuntu vm, and I'm having the same issue. Not sure if it's a bug or if I'm just missing something.

[BartMassey]

Sorry for the troubles! These kinds of problems are really hard to isolate. Things you can try:

• Use the rust-gdb shipped with Rustup instead of some bespoke GDB.
• Try the latest probe-rs: go to the probe-rs website and follow the instructions, or try cargo install --locked probe-rs-tools to get the latest version.

If these things fail, please post us a report with all the details: host platform, exact versions of things, exact commands run, etc. A problem we can reproduce is a problem we can solve.

If you figure something out, please post it here so that we can update the instructions.

[davelongdev]

Thanks for the help. I'll keep working on it.

[davelongdev]

Thank you, but neither of these suggestions worked for me.

I then tried the process again in a fresh ubuntu installation of 24.04-2 and recorded the below commands.

commands --

sudo apt update
sudo apt upgrade
sudo apt install vim
sudo apt install curl
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
(enter for standard installation)
rustup update
sudo apt install gdb-multiarch
cargo install cargo-binutils
sudo apt install gcc
cargo install cargo-binutils
rustup component add llvm-tools
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/probe-rs/probe-rs/releases/latest/download/probe-rs-tools-installer.sh | sh
(download udev rules file)
sudo cp Downloads/69-probe-rs.rules /etc/udev/rules.d/
cat /etc/udev/rules.d/69-probe-rs.rules
(shows rules in file)
sudo udevadm control --reload 
sudo apt install minicom
(enter for default)
rustc -V
cargo install cargo-binutils --vers '^0.3'
cargo size --version
cargo install --locked probe-rs-tools --force
cargo embed --version
sudo apt install git
(enter for default)
git clone https://github.com/rust-embedded/discovery-mb2.git
sudo apt install gdb-multiarch minicom libunwind-dev
sudo -e /etc/udev/rules.d/69-microbit.rules
(paste in rules

# CMSIS-DAP for microbit
ACTION!="add|change", GOTO="microbit_rules_end"
SUBSYSTEM=="usb", ATTR{idVendor}=="0d28", ATTR{idProduct}=="0204", TAG+="uaccess"
LABEL="microbit_rules_end"

)
cat /etc/udev/rules.d/69-microbit.rules
(shows rules in file)
sudo udevadm control --reload
(plug in micro:bit)
lsusb | grep -i "NXP ARM mbed"
ls -l /dev/bus/usb/001/003
(shows crw-rw----+)
getfacl /dev/bus/usb/001/003
(shows user:dave:rw-)
probe-rs list
(shows micro:bit)
cd discovery-mb2/mdbook/src/03-setup/
rustup target add thumbv7em-none-eabihf
cargo embed --target thumbv7em-none-eabihf
(shows hello world screen)
ctl-c
cd ..
cd 05-meet-your-software/
rustup target add thumbv7em-none-eabihf
(shows up to date)
cargo build --example init
readelf -h ../../../target/thumbv7em-none-eabihf/debug/examples/init
(shows stats)
cargo embed --example init
(shows gdb stub listening)
(new terminal)
cd discovery-mb2/mdbook/src/05-meet-your-software
gdb-multiarch ../../../target/thumbv7em-none-eabihf/debug/examples/init
target remote :1337

(same issue as before - hangs on continue)

[BartMassey]

Thanks for the detailed trace! I was easily able to reproduce the issue. When one runs cargo embed --example init it seems that probe-rs does not stop at the beginning of code execution as expected. Instead, it breezes right on through the program and lands in the loop at the end. It's not really "hanging": ^C will interrupt it. It's just sitting in an infinite loop.

This looks like a bug in current probe-rs; I will talk to folks.

In the meantime, once you've connected gdb (I recommend rust-gdb over gdb-multiarch, regardless of what our documentation says) with target remote :1337, try monitor reset halt. This should put you in the state where you can finish the tutorial, and is probably best practice anyhow. Let me know how it goes.

[davelongdev]

Thanks! The debug process seems to be working now with the command monitor reset halt. Not sure I'll have much time to work on this today, but I'll post a follow up when I have a chance to work through the materials a bit more. I appreciate the help.

[BartMassey]

Filed an issue with probe-rs. Will wait to see what happens.

[BartMassey]

probe-rs has a fix for this now #3449, and will push it out in the next release. Will leave this issue open for now, but it would be great if someone let me know when it can be closed.

[davelongdev]

Thanks. I've been so busy with work stuff, I haven't had a chance to work on this project lately. I'll try to take a look at the fix when I have a chance, but I'm good with closing it if it seems to have been resolved. Hopefully I'll have a chance to get back to this stuff soon.

[BartMassey]

See also #19.