4 ms·

Show HN: Unbug – Rust macros for programmatically invoking breakpoints

96 points by BrainBacon 2y ago

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.

revskill 2y ago
What does nightly mean ? I hate that you could not know a specific version of a nightly.
- nindalf 2y ago
  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.
  - jtrueb 2y ago
    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.
    - JoshTriplett 2y ago
      https://raw.githubusercontent.com/rust-lang/surveys/main/surveys/2023-annual-survey/report/annual-survey-2023-report.pdf https://raw.githubusercontent.com/rust-lang/surveys/main/sur... 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.
    - littlestymaar 2y ago
      > 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).
- dvtkrlbs 2y ago
  You can pin versions with the rust-toolchain.toml file you need to be using Rustup afaik. Nightly is just the daily builds.
  - johnisgood 2y ago
    I assume any "nightly" version would work in this context, meaning it would not refer to a version from a year ago, as it would have already been made stable by that point, right?
    - traxys 2y ago
      "nightly" versions also allow to use unstable features, and unstable features may remain so for a very long time (potentially forever) without breaking, so an old nightly could maybe work
      - johnisgood 2y ago
        Right, not everything gets merged to stable. In that case: letting us know the specifics beyond "nightly" is advisable, IMO.
        do_not_redeem 2y ago
        The readme does mention the specifics, immediately after mentioning nightly. > BREAKPOINTS REQUIRE ENABLING THE EXPERIMENTAL core_intrinsics FEATURE
        johnisgood 2y ago
        How do I know which versions of nightly support that feature, and that specific version of the feature though? I like your username.
        GolDDranks 2y ago
        Just use a recent nightly and you should be fine. Rust project doesn't offically provide support even for old stable versions, so "using nightly" with no specifics generally means using any nightly build, around or newer than, the current stable release.
- landr0id 2y ago
  It's a bit unfortunate wording but it basically requires any nightly toolchain version. It uses `std::intrinsics::breakpoint()` which is a compiler intrinstic. This has been available for a long time, but afaik will never be exposed on a stable toolchain. Per https://dev-doc.rust-lang.org/nightly/unstable-book/library-features/core-intrinsics.html 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.
JoshTriplett 2y ago
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.
- BrainBacon 2y ago
  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.
  - 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.
thramp 2y ago
Oh, that’s super clever integration with tracing. Feel free to send us a PR; we’ll link to this as a related project in the docs!
- BrainBacon 2y ago
  Thanks! I'll get a PR up shortly!
- BrainBacon 2y ago
  PR opened: https://github.com/tokio-rs/tracing/pull/3147 https://github.com/tokio-rs/tracing/pull/3147
xobs 2y ago
I find myself using debug_here (https://github.com/ethanpailes/debug-here https://github.com/ethanpailes/debug-here) which does similar things but for desktop-class debugging. It hasn't been updated in a while, but it still works for me on Windows at least.
dboreham 2y ago
We used to divide by zero but then someone decided that was ok.
merksoftworks 2y ago
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.
- landr0id 2y ago
  The pretty printers seem to break from time to time as well with compiler updates: https://www.reddit.com/r/rust/comments/1f28akn/invalid_value_for_elements_in_vec_when_viewed_in/lk4vrpl/?context=3 https://www.reddit.com/r/rust/comments/1f28akn/invalid_value...
ewuhic 2y ago
Is there a good newby tutorial on how to use debugger with Rust (and debugger in general?) No videos please.
- BrainBacon 2y ago
  I didn't come across any good ones when creating this library, but if you're using VSCode, I tried my best to make the README as beginner friendly as possible. I'm open to issues and PRs if anything is unclear. I think part of the issue is that debugging is not yet very common in the Rust ecosystem, partially due to the excellent borrow checker and error messages, but partially due to immature tooling, hence I made this to promote the practice of debugging.
nathanwh 2y ago
Neat project! Maybe this decision is copied over from unreal engine, but instead of `ensure` and `ensure_always`, having names like `ensure_once` and `ensure` would have been more clear to me.
- BrainBacon 2y ago
  I can understand where you're coming from, but when programming games you generally don't want a breakpoint to be hit more than once since you are running a loop over multiple frames. So in this case the concept of ensure_once is more common, so the shorter inverse is more convenient. Asserts should be enough to get your attention and not to annoy, so orienting it this way is a deliberate choice.
  - nathanwh 2y ago
    Ah makes sense, thank you

96 points by BrainBacon 2y ago

revskill 2y ago

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

nindalf 2y ago
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.
- jtrueb 2y ago
  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.
  - JoshTriplett 2y ago
    https://raw.githubusercontent.com/rust-lang/surveys/main/surveys/2023-annual-survey/report/annual-survey-2023-report.pdf https://raw.githubusercontent.com/rust-lang/surveys/main/sur... 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.
  - littlestymaar 2y ago
    > 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).
dvtkrlbs 2y ago
You can pin versions with the rust-toolchain.toml file you need to be using Rustup afaik. Nightly is just the daily builds.
- johnisgood 2y ago
  I assume any "nightly" version would work in this context, meaning it would not refer to a version from a year ago, as it would have already been made stable by that point, right?
  - traxys 2y ago
    "nightly" versions also allow to use unstable features, and unstable features may remain so for a very long time (potentially forever) without breaking, so an old nightly could maybe work
    - johnisgood 2y ago
      Right, not everything gets merged to stable. In that case: letting us know the specifics beyond "nightly" is advisable, IMO.
      - do_not_redeem 2y ago
        The readme does mention the specifics, immediately after mentioning nightly. > BREAKPOINTS REQUIRE ENABLING THE EXPERIMENTAL core_intrinsics FEATURE
        johnisgood 2y ago
        How do I know which versions of nightly support that feature, and that specific version of the feature though? I like your username.
        GolDDranks 2y ago
        Just use a recent nightly and you should be fine. Rust project doesn't offically provide support even for old stable versions, so "using nightly" with no specifics generally means using any nightly build, around or newer than, the current stable release.
landr0id 2y ago
It's a bit unfortunate wording but it basically requires any nightly toolchain version. It uses `std::intrinsics::breakpoint()` which is a compiler intrinstic. This has been available for a long time, but afaik will never be exposed on a stable toolchain. Per https://dev-doc.rust-lang.org/nightly/unstable-book/library-features/core-intrinsics.html 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.

JoshTriplett 2y ago

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.

BrainBacon 2y ago
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.
- 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.

thramp 2y ago

Oh, that’s super clever integration with tracing. Feel free to send us a PR; we’ll link to this as a related project in the docs!

BrainBacon 2y ago
Thanks! I'll get a PR up shortly!
BrainBacon 2y ago
PR opened: https://github.com/tokio-rs/tracing/pull/3147 https://github.com/tokio-rs/tracing/pull/3147

xobs 2y ago

I find myself using debug_here (https://github.com/ethanpailes/debug-here https://github.com/ethanpailes/debug-here) which does similar things but for desktop-class debugging. It hasn't been updated in a while, but it still works for me on Windows at least.

dboreham 2y ago

We used to divide by zero but then someone decided that was ok.

merksoftworks 2y ago

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.

landr0id 2y ago
The pretty printers seem to break from time to time as well with compiler updates: https://www.reddit.com/r/rust/comments/1f28akn/invalid_value_for_elements_in_vec_when_viewed_in/lk4vrpl/?context=3 https://www.reddit.com/r/rust/comments/1f28akn/invalid_value...

ewuhic 2y ago

Is there a good newby tutorial on how to use debugger with Rust (and debugger in general?) No videos please.

BrainBacon 2y ago
I didn't come across any good ones when creating this library, but if you're using VSCode, I tried my best to make the README as beginner friendly as possible. I'm open to issues and PRs if anything is unclear. I think part of the issue is that debugging is not yet very common in the Rust ecosystem, partially due to the excellent borrow checker and error messages, but partially due to immature tooling, hence I made this to promote the practice of debugging.

nathanwh 2y ago

Neat project! Maybe this decision is copied over from unreal engine, but instead of `ensure` and `ensure_always`, having names like `ensure_once` and `ensure` would have been more clear to me.

BrainBacon 2y ago
I can understand where you're coming from, but when programming games you generally don't want a breakpoint to be hit more than once since you are running a loop over multiple frames. So in this case the concept of ensure_once is more common, so the shorter inverse is more convenient. Asserts should be enough to get your attention and not to annoy, so orienting it this way is a deliberate choice.
- nathanwh 2y ago
  Ah makes sense, thank you