-
Notifications
You must be signed in to change notification settings - Fork 758
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
debug: warn users when build flags strip debug info #182
Comments
cc @suzmue |
I am not getting any issues with just "-s". E.g. with just dlv:
But I am seeing a similar failure with "-s -w":
In vscode the main indicator that launching a debug session failed is the fact that there is no Debug toolbar (with pause, step, etc), which appears and almost immediately disappears. If all the logging is disabled the following will appear in the DEBUG CONSOLE:
It might be awkward to parse stderr for messages, but we definitely know when we get an error code from the process and could do better reporting there: vscode-go/src/debugAdapter/goDebug.ts Line 697 in 3493cfe
So is our goal here to (1) proactively parse the build flags, recognize problematic ones and warn the users as they fill out the launch configuration or launch the debug session (e.g. in case it succeeds but might result in unexpected odd behavior) or (2) do a better job channeling the launch/attach failure messages from |
Thanks @polinasok for looking into it. As we discussed offline, I agree that 2 is favorable if we do anything for this issue - because what flags are acceptable or compatible is primarily a business between We also discussed utilizing a better UI element (e.g. show message popup, or report as an error, etc) in the future once we start using |
For full transparency, we kind of entered a gray territory of making flags our business when removing If the user supplies something that completely breaks debugging (e.g. When suggesting that we improve error reporting here, I was thinking we should make sure to have a pop-up with an error message for better visibility. The only way I know how to trigger this is with an
But I see no pop-ups for this error! Compare this to the case where dlv fails because you have a syntax error. You get 2 pop-ups - one at the top because this is a launch failure and one on the bottom because of showUser. I am not sure why there is such a difference. In any case, I checked and
|
@aarzilli Should dlv always fail with |
I see what the issue is in the current adapter. We send two launch responses. One successful when dlv launches (we do get
|
To answer my own question earlier, it appears that On Linux
On MacOS
For reference:
|
Looks like a linker bug. |
@aarzilli Looking at this and dlv repo, there are many issues where confused users don't understand what "decoding dwarf section info" errors mean. "could not open debug info" is slightly better, but still confuses people. I was about to add an FAQ entry, debating if it belongs in vscode-go docs and/or dlv docs, but now I am thinking that perhaps it would be better to somehow print more informative error messages in such cases, pointing out that users must not use -s -w link flags or use go run? WDYT? |
I'm skeptical that it will help, but we can try. |
IMO an FAQ entry in vscode-go docs is better in this case because On the other hand, When users of the command line tool |
What do you mean? |
All the configuration massaging in src/goDebugConfiguration.ts and the future change described in #128. |
Change https://go.dev/cl/396882 mentions this issue: |
Updates #182 Change-Id: I056edb1056499d714ae303988366780fa5620cdc GitHub-Last-Rev: 52890f1 GitHub-Pull-Request: #2152 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/396882 Trust: Jamal Carvalho <[email protected]> Reviewed-by: Hyang-Ah Hana Kim <[email protected]>
The above error change was merged. The documentation has been updated. |
This is copied from the original issue: microsoft/vscode-go#2783.
The user had set
--ldflags "-s"
as build flags, which were stripping debug information. We should surface an error message when users try to debug binaries built with these flags.The text was updated successfully, but these errors were encountered: