Is there any way to set up lauch.json file, so that we can debug Go file with GDB using VSC?
lauch.json won't be enough to achieve that. To actually use GDB from VS Code you will need a plugin supporting GDB. You can probably try "Native Debug" plugin for that. But I'd like to point out that GDB has several issues with debugging Go programs. And generally recommended debugger for Go is delve. And debugging with delve is supported (among many other things) by "Go for Visual Studio Code" plugin. Both plugins include detailed instructions on necessary configuration.
Related
I want to write an extension for Visual Studio Code (VSCode) which will allow me to debug a C++ program with Visual Studio's native C++ debugger instead of gdb (which currently is the only option VSCode supports). I looked at the Visual Studio Debugger Extensibility. But it only explains how you can create a new debug engine and call it from Visual Studio as a front end. What I want to do is the opposite. I want to call the existing Visual Studio C++ debug engine from a different front end, which happens to be VSCode. There is no documentation on the Internet how I can achieve this. Can anyone please help?
I'm on the VSCode team. To use the VS debugger from VSCode, you will need to author a debug adapter extension. Here's some documentation on getting started, and here's the complete debug adapter protocol reference.
Try look at some existing implementations to get started:
Mock debugger – simple example debugger
Node debugger - node.js debug adapter
For C++, also check out C++ tools for VSCode.
Hope that helps.
Edit - Seems I misunderstood the problem. Here are some thoughts on consuming the VS C++ debugger from an external application.
To my knowledge, Visual C++ does not have public APIs or interfaces that allows external programs to easily interface with them. Other languages have better stories, since they often leverage external libraries or were designed with documented debugger protocols. The GDB machine interface is a good example of this sort of design.
My best suggestion is that you could try to leverage the Visual Studio Env.DTE interfaces to control VS programmatically. EnvDTE is not well documented and may not be exactly what you are after, but it is pretty powerful.
Can anyone tell me how can I run and use debugger in Visual Studio for a simple go program in Windows step by step?
I took a reference from this page:
https://marketplace.visualstudio.com/items?itemName=lukehoban.Go
But I was not able to run the code. My current GOPATH is C:\dev\go.
Please let me know if any other details are required.
First of all, debuggers are not part of Go. C#, F# and other managed languages under the Microsoft stack have debuggers as that's part of the .NET stack.
Second, Visual Studio Code != Visual Studio. VS Code is a light(er) weight IDE that is geared towards extensibility to support a wide range of languages by creating runners. But that's the thing: someone else needs to write the runners and hopefully they created a seamless experience with a Debugger (if available). This is why you have multiple versions of language runners.
In other words: if you want a VSCode-compatible Debugger+Runner for X language, read up on X language about how to debug it.
Go is no exception. You must read the language spec, and specifically I recommend Effective Go as it explains why you don't need a Debugger.
--
Now with all of that said, the community has come together and created somewhat of a debugger for GoLang. It is called Delve.
Learning how to install it for VS Code is beyond this post. I recommend finding a VSCode package that supports Go coding with Delve (there is at least one out there, as I have used it).
Opinion: it's an Ok experience in VSCode to debug Go. I've experimented with it. While visually pleasing, I went back to Atom for it's large package support of many other Go utilities and Linters - most of which is missing in VSCode (and some packages didn't allow me to modify the config to exclude certain Go workflows).
EDIT 2018: After a few years, VSCode has matured nicely! I've since switched 100% to VSCode as my primary editor.
One possible option to install Debugger for Go language on Windows is:
go get github.com/derekparker/delve/cmd/dlv
After that the Visual Studio Code (vscode) will be able to run (debug) launch configuration.
By default, file launch.json points to the root of the project:
"program": "${workspaceRoot}"
If you want configure it to the another location (eg. your/package/foo/dir) then edit it as the following:
"program": "${workspaceRoot}/foo/dir"
In case you want to debug a Go module running inside an application server you can have a look at debugging golang appengine module with visual studio code.
Explanations are for Appengine server, but you can easily understand how to do remote debugging from vscode using Delve.
I installed MinGW and created a makefile project on Visual Studio Community 2015 today and got it working for compilation.
Still two things are bugging me:
Interface
I can't tell Visual Studio to prevent closing the console window after running the program. Even Start Without Debugging closes the window and the project properties are not the same as a normal VS project, so I don't know how to configure this.
Debugging
Setting breakpoints is hopeless. Apparently the debugger won't understand debug info from files compiled with other compilers. I get Module was built without symbols..
I've tried setting up gdb according to this answer, but then starting the debugger lead me to this window:
which indicates that the executable has indeed debugging symbols (I'm compiling with -g)
I can feel I'm getting pretty close. What am I missing?
mingw-gcc generates DWARF format debugging information in its
executables. The Visual Studio debugger expects separate PDB
debugging files as produced by Microsoft's compilers. It can't
recognize DWARF.
You can debug MinGW executables either with
the gdb console, as you have almost started to do, or for
"visual" debugging you can do it in an IDE that supports gdb,
on Windows, such as CodeLite, Eclipse-CDT, CodeBlocks. If you
are wedded to Visual Studio you might try your luck with
Microsoft's open sourced Visual Studio MI Debug Engine ,
which according to its blurb "enables debugging with debuggers that support the gdb Machine Interface ("MI") specification such as GDB, LLDB, and CLRDBG".
I know nothing more about it
I am new to win32 programming and also to driver programming. I have installed Windows DDK on my system and have got some examples with the DDK but those examples don't have dsw file.
I wanted to know how can I create .dsw file so that I can open that workspace in VC6.
Most people who build DDK/WDK projects in Visual Studio do so using a 'makefile' project that invokes the DDK's build.exe utility. This works quite well- you get the code navigation capabilities of Visual Studio while building your DDK project using the standard, supported DDK tools.
Note that the DDK comes with it's own set of compilers, and those compilers should be used to build DDK projects.
OSR has a little set of cmd scripts that is supposed to make this easier (it's been years since I've done anything with those; I really can't remember how well they work):
http://www.osronline.com/article.cfm?article=43
Another similar tool is available from Hollis Technology:
http://www.hollistech.com/Resources/ddkbuild/ddkbuild.htm
As far as debugging goes, unfortuantely the VS debugger won't work for kernel mode driver debugging. For that, get the Debugging Tools for Windows package which has a great set of debuggers. The GUI debugger, WinDbg, is quite nice even if it's not quite up to the usability of Visual Studio's. And the documentation with the Debugging Tools is outstanding - you can learn a lot about Windows internals just by reading the WinDbg docs.
The last time I looked (which was years ago), you don't build device drivers using the Visual Studio IDE: the DDK has its own build.exe utility (similar idea but not the same as makefiles); and apparently this is still true as of early 2008, see for http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/4382c9b66f8611e9?pli=1
I expect that "how to build" is described in the DDK documentation.
I think better you integrate with Visual Studio 2005, 2008 or 2010 with this tool:
http://visualddk.sysprogs.org/versions/1.5.6
ChrisW is correct, you can't use Visual Studio (unless there is a way to set it).
Anyway, for start debugging you can use DebugView to print simple messages with DbgPrint.
VC6 is very old these days, can't you use a newer version? Anyway, as I recall, you can just open the project file as a workspace, the IDE will create the .dsw file for you.
My C# code is calling an unmanaged third-party library function via P/Invoke, and the unmanaged function is having some strange side effects. I want to debug into it and see what it's doing.
If I debug my C# code, and try to "Step Into" the P/Invoke call, it steps over instead. No surprise there -- I expected that; it doesn't have the source for this DLL, and I didn't tell it I was okay with seeing the disassembly view.
So I switch the debugger to disassembly view (Debug > Windows > Disassembly). Now I see the individual x86 instructions in my JITted code. Again I try to step into the P/Invoke call. Again, it steps over instead -- even though I clearly told it to Step Into an x86 CALL instruction. How hard is it to step into an x86 CALL?
My Googling thus far has shown me a couple of options that can affect this, and I've already set them:
In Tools > Options > Debugging > General, "Enable Just My Code" is unchecked.
In Project > Properties > Debug tab, "Enable unmanaged code debugging" is checked.
No good. Visual Studio still refuses to step in.
I don't have a PDB for the third-party DLL, but that shouldn't matter. I don't care about source code or symbol information. (Well, actually they'd be really nice, but I already know I'm not going to get them.) Visual Studio can do x86 debugging (that's what the Disassembly view is for), and all I want to do is step into the x86 code.
What else do I need to do to get VS to allow me to step into the x86 instructions inside a P/Invoke call?
This may help you solve the problem:
(by Graviton)
CallingConvention = CallingConvention.Cdecl
Also this mentions that you need to detach managed debugger and re-attach unmanaged when crossing the boundaries. You might need to check the capabilities of mixed debugger and it's preferences from MSDN.
And finally, using Ed Dore' answer:
Under Tools.Options dialog, select the
Debugging category, and make sure the
"Enable Just My Code" setting is
unchecked. From the Project
properties, select the Debug tab, and
then ensure that "Enable unmanaged
code debugging" is checked.
Once you've got these squared away,
you should get the mixed mode
debugging support working.
Also, if you use "Debug.Attach To
Process" , be sure to hit the
"Select..." button in the "Attach To
Process" dialog, and select both
Managed and Native debugging support.
One thing I would try is going from C# to C++/CLI code, and then from C++ to the third-party code. Once you're in C++ (and free of the P/Invoke infrastructure), you might have better luck with the disassembly view.
In your C# project properties, in the Debug tab, check Enable native code debugging. Worked for me in VS 2012.
Credit goes to billb.
Also, since it's a third party library, ensure Enable Just My Code is unchecked in Options > Debugging.
I had a similar issue where I was debugging a C# exe that called my own C++ dll via PInvoke, all part of the same solution. Enabling native code debugging in my c# project allowed me to debug my C++ code.
Had same issue today.
What helped in my case was to run Visual Studio as administrator.
My setup:
Visual Studio 2019
Windows 10