-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/compile: emit a safe point after every instruction #57719
Comments
Actually, the compiler marks "unsafe points" for places that are not safe to be interrupted, and everywhere else is considered a safe point. In that sense, it is already safe point almost everywhere, except in a few specific places. The "call not at safe point" is due to that the stopped place is in the small range that are marked as an unsafe point. Could you show the source code and the disassembly of the stopped function? So we can see if there is anything we could do to improve the unsafe point situation. Thanks. I'm not sure we can eliminate unsafe points entirely, as there are places where it is actually unsafe to make a call. Maybe certain functions are okay, but we don't know. Or maybe in some cases the debugger could single step to the end of the unsafe point (depending on the nature of the unsafe point, this may or may not change the program's state). |
I'm taking this out of the proposal process, as it is not an API change. |
Got a reproducer offline. It seems the compiler marks some seemingly safe code as unsafe points. Still looking into why this happens. |
FYI unsafe point marking for write barriers will change in 1.21, due to https://go-review.googlesource.com/c/go/+/447777 (and related CLs). |
Found the problem. For example, for this code
it looks pretty safe. In particular, the store
This is due to
Due to this, any code before a range loop from the last call or function entry would be marked unsafe. The unsafe pointer conversions for |
It might also be possible to eliminate the uintptr->unsafe.Pointer marking. This is subtle. I'll need to think more carefully. |
Change https://go.dev/cl/461696 mentions this issue: |
I am not familiar with Go compiler internals, so it is possible that the wording in the issue title is wrong. However, the request from the user perspective is to have a safe point for every place in the code where Delve can stop. This is not the case right now and occasionally Delve rejects evaluating an expression due to a missing safe point:
I find it difficult to predict where safe points exists, so I just keep stepping forward and retrying the
call
command until it succeeds (not always the case). This significantly degrades the debugging experience for me, which is why this issue.Note that a similar request was filed in go-delve/delve#3175 a few months ago, but it was closed because it requires a change in the Go compiler and not Delve.
The text was updated successfully, but these errors were encountered: