Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Unbug – Rust macros for programmatically invoking breakpoints

github.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#21

Post by amluto »

BrainBacon wrote: post #13
JoshTriplett wrote: post #6

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 pro…

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.

Hah, the README says:

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

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

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#23

Post by JoshTriplett »

amluto wrote: post #20
JoshTriplett wrote: post #6

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 pro…

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 w…

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?

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#24

Post by BrainBacon »

amluto wrote: post #21
BrainBacon wrote: post #13

Earlier quoted context omitted.

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.

Hah, the README says: > Additonally, debugging may not land on the macro statements themselves. See my comment above, and give int3;nop a try.

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.

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#25

Post by merksoftworks »

Rusts current pretty printers in lldb and gdb are just not good enough for a fluid step debugging experience. I've had luck with intellij IDE's but it's very sad that the best we can do in a language with such good devex tooling is print debugging.

Theoretically you could generate debug scripts with a macro and embed them with

  #![debugger_visualizer(gdb_script_file = "../foo.py")]
but I haven't seen anyone go through the trouble.

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#26

Post by rep_lodsb »

amluto wrote: post #20
JoshTriplett wrote: post #6

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 pro…

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 w…

The "canonical" INT 3 is a single byte opcode (CCh), so the debugger can just subtract 1 from the address pushed on the stack to get the breakpoint location.

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.

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#27

Post by estebank »

JoshTriplett wrote: post #6

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 pro…

Having a feature like this will significantly increase the demand of better incremental compilation, potentially with the need for patching specific items on existing binaries for speed. At that point you could get very close to an IDE debugging experience/speed with only rustc, a text editor and a debugger. (Inserting a bunch of NOPs on every function and supporting patching of JMPs in their place would likely go a long way for this.)

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#28

Post by littlestymaar »

jtrueb wrote: post #5
nindalf wrote: post #3

Earlier quoted context omitted.

The master branch of the Rust repo is built every night and distributed. That's a nightly build. Most people are on the stable release, which is updated every six weeks. 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.

Is it a minority? Are there stats posted for this? Only recently have I had some projects switching to stable after their required features stabilized.

> Only recently have I had some projects switching to stable after their required features stabilized.

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).

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#29

Post by kookamamie »

dvtkrlbs wrote: post #4
revskill wrote: post #2

What does nightly mean ? I hate that you could not know a specific version of a nightly.

You can pin versions with the rust-toolchain.toml file you need to be using Rustup afaik. Nightly is just the daily builds.

I thought nightly is for nightly builds. I'll get my coat.
Post reply on HN