←back to thread

88 points BrainBacon | 1 comments | | 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 ◴[] 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 #
amluto ◴[] No.42195778[source]
Plain int3 is a footgun: the CPU does not keep track of the address of the int3 (at least not until FRED), and it reports the address after int3. It’s impossible to reliably undo that in software, and most debuggers don’t even try, and the result is a failure to identify the location of the breakpoint. It’s problematic if the int3 is the last instruction in a basic block, and even worse if the optimizer thinks that whatever is after the int3 is unreachable.

If Rust’s standard library does this, please consider using int3;nop instead.

replies(2): >>42196045 #>>42196978 #
1. JoshTriplett ◴[] No.42196045[source]
Good to know! I've seen the pattern of "int3; nop" before, but I've never seen the explanation for why. I'd always assumed it involved the desire to be able to live-patch a different instruction over it.

In Rust, we're using the `llvm.debugtrap` intrinsic. Does that DTRT?