[BrainBacon]

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.

[nulld3v]

On Unix platforms, you could just raise SIGTRAP directly, it will pause the attached debugger and works regardless of architecture.

This is the macro I use for example:

  #[doc(hidden)]
  pub use libc as __libc;
  
  // This is a macro instead of a function to ensure the debugger shows the breakpoint as being at
  // the caller instead of this file.
  #[cfg(unix)]
  #[macro_export]
  macro_rules! breakpoint {
      () => {
          unsafe {
              use $crate::__libc as libc;
              libc::raise(libc::SIGTRAP);
          }
      };
  }

[amluto]

Hah, the README says:

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

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

[BrainBacon]

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.

[BrainBacon]

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.