-
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
|
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. |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
I think that the FCP should be cancelled and restarted, considering how there was a lot of questioning about where this should be located. Especially considering how it was libs nominated a week ago. |
We discussed this at length in last week's @rust-lang/libs-api meeting, and brought it up again in this week's meeting. Summary of that discussion:
Given all of the above, we were fine going ahead with the stabilization. We would also be open to ACPs for additional items, such as a hint that produces a breakpoint if and only if a debugger is attached. |
As a reminder for whoever puts up the stabilization PR, please nominate it for lang to review stable use of the intrinsic. |
Was |
Although I personally dislike the decision, I think that the libs team isn't going to be particularly swayed by further bikeshedding, and so we shouldn't really comment anything else here unless it pertains to stabilising what's proposed as-is. |
Stabilization report and FCP in rust-lang#133724.
I'd still love to see an answer to this, I don't think there has been one? But yeah it seems too late... this feels a bit rushed given the amount of concerns and questions raised here.
Is there a writeup somewhere of why these semantics are desired? "stop if debugger is attached, ignore otherwise" seems like a much more desirable semantics to me. |
A higher level And the debug or abort behaviour is useful even if we had a function with different semantics. |
The primary motivation, at least according to the ACP, is to be able to have this available on I've mentioned my arguments for why I think such a method should not be given a friendly name like |
So the argument is "because that's what the system API provides, we don't have a choice here"?
That's an assertion, not an argument. |
Sure? You asserted that "stop if debugger is attached, ignore otherwise" is "more desirable". I did not take from that that you were requiring justification for any other behaviours being available in the standard library. |
It emits a debug breakpoint instruction, or a trapping instruction if the target doesn't have a breakpoint instruction. Either way, that will have the behavior of aborting the program if not handled. On Linux, for instance, it'll result in the program receiving a SIGTRAP signal. The description of the function as aborting the program by default if not handled is very much part of the definition, and intended to be normative. Users can rely on it. Does that answer your question? |
No, some of the arguments are:
All that aside, it's a matter of debugging style and preference whether you want the "breakpoint if debugger attached" operation or the "breakpoint unconditionally" operation. The former can be built atop the latter, but the latter can't be built atop the former, and the latter is a useful operation to have. |
You’ve stated what the function’s definition is and that “users can rely on it” but that doesn’t get to the heart of the question. Why is the definition like that, why and how is this definition useful to users? Would users complain or write their programs differently if
Note that these questions are not coming from a preference for a different API (like “breakpoint under debugger, nop otherwise”) but from a language spec perspective: how and why is this “guarantee” you’re describing different from what the functions in |
That's not what I said. "breakpoint if debugger attached" isn't sufficient to leave the operation in place in production without some other conditional attached to it. In some production environments, it might make sense to deploy a binary that does have a breakpoint with a conditional wrapped around it, controlled by (for instance) a special option you can pass. But in the absence of such an additional conditional, a binary with a "breakpoint if debugger attached" such a binary would break if you tried to
Yes, that would break user expectations. As one of many potential examples, you may want to run it without a debugger, expecting it to produce a coredump when it hits the breakpoint.
That part of the behavior is target-specific, and if a target didn't have any mechanism for resuming execution, that wouldn't prevent aborting.
That would depend on the nature of the issue, the debugger, and what the standard conventions on the target are. If it's the standard breakpoint of the platform and the debugger doesn't recognize it, that sounds like an issue in the debugger. But if there's some convention we failed to follow, and a proposed modification still works with other debuggers, it might be something we'd want to fix.
That would be less useful, for multiple reasons. Among them: you might not want to panic, because that's harder to step "around" than a breakpoint instruction. Also, a panic errors in a different way,
That would be less convenient, and additionally would not abort the program if hit without a debugger attached, and additionally |
Josh claimed that what core does is the "desired semantics", implying that other semantics are not desired. I asked for justification, since I can totally see other semantics being "more desirable". I'm not the one trying to add something to our stable API surface here, so it is not me who has the burden of justification. If it was just about one gut feeling for what is desirable vs another, surely we should wait a bit longer and see whether we can find any actual arguments.
That very much sounds like "because that's what the system API provides, we don't have a choice here" to me. (I infer that the semantics of "only break under debugger" cannot live in core.) To be clear, that's a reasonable argument as far as I am concerned. I think it's just the name that is confusing for people not familiar with the details of assembly instructions, people that only ever used breakpoints in an IDE. |
@joshtriplett Answering specific illustrative examples unfortunately doesn’t tell me directly what you think about the nature of this “guarantee users rely on” and I don’t want to assume. It feels unproductive to repeat it several times but I still haven’t gotten a straight answer how the points you made are not just QoI concerns. Is the (lack of) “guarantee” about what |
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: