-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tracking Issue for breakpoint
feature (core::arch::breakpoint
)
#133724
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Is there a reason why this is in Plus, |
Does it really fit in It fits better in there but it doesn't feel like the obvious place to look for a breakpoint function |
@clarfonthey I don't think "do nothing" should be a valid implementation of this. "abort" is a valid implementation. Given that, I don't think this belongs in That said, that doesn't necessarily make I don't see any existing module that this logically fits in other than We could put it in a new |
I mean, sure, but we have other things in |
@clarfonthey AFAICT, every function in A breakpoint isn't a "hint"; it can't be replaced with a no-op. Is there any other module in |
JavaScript has the |
@kpreid I'd love to have that operation, but unfortunately, that's a much more complex operation that isn't as simple as emitting an instruction, it'd be more error-prone (it can erroneously detect a debugger), it'd be less portable (as it's OS-specific rather than CPU-specific), and it wouldn't be available on all targets. |
@joshtriplett Maybe an ACP for debugger presence detection? C++ 26 is getting that. I recently added debugger presence detection to Unbug using the dbg_breakpoint crate. The bulk of that crate was previously accepted as a panic hook in the Rust standard library, but then reverted later. |
Stabilization ReportImplementation HistoryApproved in ACP rust-lang/libs-team#491 , implemented in #133726 , and not modified since. Includes tests and documentation. Some discussion about what the correct module for this function should be, but no conclusion about a specific better place than API SummaryIn pub fn breakpoint(); Experience ReportThe ACP was originally inspired by the |
@rfcbot merge |
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
@rustbot labels +I-lang-nominated +P-lang-drag-1 Generally we lang FCP the first stable use of an intrinsic. This is an intrinsic, and this is the first stable use. At the same time, as we discussed in the libs-api meeting today, perhaps what we're meaning to lang FCP are new capabilities of the language, and this one could be seen as equivalent to some inline assembly. So I don't know. It's worth us having a look in any case, so let's nominate. cc @RalfJung @workingjubilee @rust-lang/lang |
This doesn't really have semantics so I don't think there's much to say here from the opsem side. |
The semantics are essentially:
|
The "trap" part seems like a somewhat "new capability" for |
I'm still not 100% convinced on this being in That said, the closest analogue that seems to exist is Perhaps |
Also, regarding these arguments for
Now that |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Actually, that being the case now means that it probably is best to put this in |
We did discuss
|
FWIW, I think |
As I mentioned, I also think that there would be room to add |
@hanna-kruppe I disagree; it'd be just as easy to interpret "debugtrap" as "trap only when debugging". "breakpoint" emits a target-specific breakpoint instruction, and the normal behavior of such an instruction is to trap. |
I think that's a lang question -- is whether a debugger is attached observable behaviour? Is it part of the Rust AM state? Are we allowed to move this around relative to other non-observable statements? It reminds me of the "non-temporal store" issue, making me think
isn't enough to describe what its Rust semantics are, just like "well it does a target-specific non-temporal store" wasn't enough. TBH, I would also have expected FWIW, fatally trapping being the default behaviour is surprising to me -- I'd pattern-matched it to https://learn.microsoft.com/en-us/dotnet/api/System.Diagnostics.Debugger.Break?view=netframework-4.8.1 which is different from https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.debugger.launch?view=netframework-4.8.1. I'd have thought it does nothing if there's no debugger attached. |
"do nothing" isn't intended to be a valid implementation of At least on Linux, behaving differently if a debugger is attached is a more challenging and finicky proposition, and I wouldn't expect any debugger-dependent behavior to be something we'd be able to reliably support across a majority of targets. |
Does that make any difference from a language/spec perspective? Are users expected to rely on this “by default” aborting the program, and if so, how? Basically: what makes a “do nothing” implementation of |
@rustbot labels +T-lang -I-lang-nominated +I-lang-radar -P-lang-drag-1 We discussed this in the lang call today. Given what @scottmcm said above, the PR to stabilize the use of this intrinsic is going to need a lang FCP. That is, it's OK for this libs-api FCP on the issue to complete as-is (or not), but please nominate the stabilization PR for lang, and please include a lang stabilization report in that PR that addresses the normal items and those raised by @scottmcm. |
No, it should not be the only thing; it should be joined by the stable version of |
The argument that was made in the libs-api meeting against |
Yes, that is a good argument for a different name ( (A third option is to put it directly in the root of |
One argument in favor of |
A fourth function that might be useful in this hypothetical module, is |
Renominating so a subsequent meeting can do further bikeshedding. |
Uh oh!
There was an error while loading. Please reload this page.
Feature gate:
#![feature(breakpoint)]
This is a tracking issue for the
breakpoint
feature, which gates thecore::arch::breakpoint
function. This feature was approved in ACP 491.Public API
Steps / History
core::arch::breakpoint
libs-team#491core::arch::breakpoint
and test #133726Unresolved Questions
Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩
The text was updated successfully, but these errors were encountered: