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.
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.
If Rust’s standard library does this, please consider using int3;nop instead.
In Rust, we're using the `llvm.debugtrap` intrinsic. Does that DTRT?
There is another encoding (CD 03), but no assembler should emit it. It used to be possible for adversarial code to confuse debug interrupt handlers with this, but this should be fixed now.
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);
}
};
}> Additonally, debugging may not land on the macro statements themselves.
See my comment above, and give int3;nop a try.
Theoretically you could generate debug scripts with a macro and embed them with
#![debugger_visualizer(gdb_script_file = "../foo.py")]
A minority use the nightly build for various reasons: a feature that hasn't reached stable yet, or because they want to help test the nightly releases and prevent bugs from reaching stable.
Only recently have I had some projects switching to stable after their required features stabilized.
Per https://dev-doc.rust-lang.org/nightly/unstable-book/library-...
>This feature is internal to the Rust compiler and is not intended for general use.