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

11–20 of 41 posts

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

#11

Post by johnisgood »

traxys wrote: post #9
johnisgood wrote: post #7

Earlier quoted context omitted.

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?

"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

Right, not everything gets merged to stable. In that case: letting us know the specifics beyond "nightly" is advisable, IMO.

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

#13

Post by BrainBacon »

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.

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

#16

Post by do_not_redeem »

johnisgood wrote: post #11
traxys wrote: post #9

Earlier quoted context omitted.

"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

Right, not everything gets merged to stable. In that case: letting us know the specifics beyond "nightly" is advisable, IMO.

The readme does mention the specifics, immediately after mentioning nightly.

> BREAKPOINTS REQUIRE ENABLING THE EXPERIMENTAL core_intrinsics FEATURE

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

#17

Post by johnisgood »

do_not_redeem wrote: post #16
johnisgood wrote: post #11

Earlier quoted context omitted.

Right, not everything gets merged to stable. In that case: letting us know the specifics beyond "nightly" is advisable, IMO.

The readme does mention the specifics, immediately after mentioning nightly. > BREAKPOINTS REQUIRE ENABLING THE EXPERIMENTAL core_intrinsics FEATURE

How do I know which versions of nightly support that feature, and that specific version of the feature though?

I like your username.

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

#19

Post by GolDDranks »

johnisgood wrote: post #17
do_not_redeem wrote: post #16

Earlier quoted context omitted.

The readme does mention the specifics, immediately after mentioning nightly. > BREAKPOINTS REQUIRE ENABLING THE EXPERIMENTAL core_intrinsics FEATURE

How do I know which versions of nightly support that feature, and that specific version of the feature though? I like your username.

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.

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

#20

Post by amluto »

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 whatever is after the int3 is unreachable.

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

Post reply on HN