-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: optimization around runtime.throw breaks delve DAP #62523
Comments
I dug into this a bit. In fact the DWARF for It sounds as though any special treatment that Delve has for 'runtime.throw' may need to be extended to |
I don't think that we do anything special for either, it's just reading the s argument, it's the same code for both and it's probably broken for both of them. I haven't bisected the problem but I would expect this to be caused by a compiler change. Looking at this more it looks like the problem only happens when the program is compiled with |
Bisecting seems to point the finger at https://go-review.googlesource.com/c/go/+/521699, which makes sense based on the commit message. I'll look a bit more tomorrow. |
When building the runtime with "-gcflags="all=-l -N", it looks as though when we execute this code here: At that line there is a check made to see if "base.Ctxt.Flag_optimize" is set, this check is failing, which causes the code to drop back down into the ABI0 case. The problem from CL 521699 appears to be in this line here: which sets "base.Flag.N" to 0, but doesn't correspondingly update base.Ctxt.Flag_optimize (which was set previously on line 274 based on the original value of -N). I'll send a CL. Also kind of makes me wonder whether we should still have both "base.Flag.N" and "base.Ctxt.Flag_optimize"; I think the latter was important back before big rsc refactor. |
Change https://go.dev/cl/527319 mentions this issue: |
Change https://go.dev/cl/526836 mentions this issue: |
This patch fixes an inconsistency in compiler flag handling introduced accidentally in CL 521699. In the compiler we have both base.Flag.N (which records whether the user has supplied the "-N" flag to disable optimization) and base.Ctxt.Flag_optimize (which tracks whether optimization is turned on). In this case Flag.N was updated without a corresponding change to Ctxt.Flag_optimize, which led to problems with DWARF generation for the runtime. This CL doesn't include a regression test; a test will be added later in the x/debug repo in a subsequent CL. Updates #62523. Change-Id: I0c383bb43ec0a0e7c12e7e2852c0590731416d6f Reviewed-on: https://go-review.googlesource.com/c/go/+/527319 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
New issue in the current tip/1.22.
From @aarzilli : go-delve/delve#3455 (comment)
go-delve/delve#2616 description explains how delve is currently extracting the reason info.
From @thanm : look into extending the existing x/debug/dwtest tests to catch this type of regression.
The text was updated successfully, but these errors were encountered: