←back to thread

Show HN: Unbug – Rust macros for programmatically invoking breakpoints

(github.com)
88 points BrainBacon | 1 comments | 20 Nov 24 13:33 UTC | HN request time: 0s | source

This project is inspired by some of the asserts in Unreal engine.

Due to reliance on core_intrinsics it is necessary to develop using nightly Rust, but there are stubs in place so a production build will not require nightly.

I recently released version 0.2 which includes no_std support and adds optional log message arguments to the ensure macro.

Show context
JoshTriplett ◴[20 Nov 24 14:10 UTC] No.42194057[source]▶
You could potentially build on stable Rust by emitting the breakpoint instructions yourself, at least on popular platforms. For instance, `core::arch::asm!("int3")` on x86, or `core::arch::asm!("brk #1")` on ARM.

Also, this is providing motivation to want to stabilize a breakpoint mechanism, perhaps `core::arch::breakpoint()`. I'm going to propose an API Change Proposal (ACP) to the libs-api team to see if we can provide that in stable Rust.

replies(3): >>42194435 #>>42195778 #>>42197034 #
BrainBacon ◴[20 Nov 24 14:57 UTC] No.42194435[source]▶
Thanks, yeah I considered using the instructions directly, but I was hoping for a more cross-platform option. For my purposes, developing in the Bevy engine, nightly isn't a huge blocker. Yeah, it would be really great to just have breakpoint support in stable Rust, thanks for doing the proposal! I'll consider stable support in the meantime.
replies(1): >>42195802 #
amluto ◴[20 Nov 24 16:52 UTC] No.42195802[source]▶
Hah, the README says:

> Additonally, debugging may not land on the macro statements themselves.

See my comment above, and give int3;nop a try.

replies(1): >>42196271 #
BrainBacon ◴[20 Nov 24 17:32 UTC] No.42196271[source]▶
Interesting. Unfortunately, I'm not well versed in assembly, is there a similar trick or requirement in arm and would that include Apple silicon, or is this something specific to `int3` on x86? That may explain why it was inconsistent during my development process, I didn't think to check if the inconsistency was platform dependent.
replies(1): >>42199635 #
1. BrainBacon ◴[21 Nov 24 00:15 UTC] No.42199635{3}[source]▶
Answering my own question, apparently `brk #1` is insufficient on Apple silicon. That results in just a trap and will prevent the debugger from continuing past the debug statement. From a bit of searching and my experiments `brk #0xF000` was the way to go instead which had the consequence of not always landing on the debug statement, the addition of a nop with `brk #0xF000 \n nop` resulted in the debugger landing on the correct statement.