4 ms·

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, ni

• amluto 2y ago
  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 2y ago
    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 2y ago
      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.
• nulld3v 2y ago
  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); } }; }