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.

int3 is a "trap". continue will resume execution at the instruction after int3, as intended. But backtrace should, by some ill-defined magic, generate the backtrace as though RIP was (saved RIP - 1). And the condition for doing this isn't something that is (AFAIK) representable at all in GCC's worldview. Sure, GCC knows, or at least ought to know [0], that it gained control because of vector 3, and the Intel and AMD manuals say that vector 3 is a trap. But there isn't a bit in memory or anything you would see in 'info regs' that will say "hey, this is a 'trap', and backtraces and such should be done as though RIP was actually RIP-1".

Maybe the right solution would be to split the program counter, from the perspective of the debugger, into two fields: program counter for backtracing, and program counter for resumption.

And yes, I know that GCC gets this wrong. Been there, seen the failures. I have not checked, but I expect that LLDB works exactly like GCC in this regard.

[0] ptrace on Linux exposes the vector number, somewhat awkwardly. Or you can infer it from the fact that the signal was SIGTRAP.

Seems like a deficiency in GDB (and maybe LLDB too), not in the kernel or x86.

Deficiency or not, it breaks debugging. I’m willing to pay a cost of one byte per breakpoint as a workaround.

And GDB has far more outrageous, if less-frequently hit, bugs in its architectural state handling. I’m not holding my breath for a fix.

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.

89.4% of users surveyed use stable. 31.1% use nightly, but there's overlap there (e.g. I use nightly to try out new things but don't build things that depend on nightly). Only 11.5% of people say they use a crate that requires it.

While this used to be very common back then (in 2016-18 many things where progressively stabilized and you had cornerstone libraries switching to stable at almost every release) it hasn't been so for the past 5 years.

Rust gets way less “exciting” new features nowadays, as the language has settled a lot (there are still moving parts, but they are the minority not the norm).

> BREAKPOINTS REQUIRE ENABLING THE EXPERIMENTAL core_intrinsics FEATURE

I like your username.

That obviously only works for non-library uses of nightly.

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.