Search code examples
c++gdbvisual-studio-2017remote-debuggingvisual-studio-debugging

Debugging Library Code with Visual Studio's Linux support

I'm using Visual Studio 2017's integration to build and debug a CMake Linux application locally in the Windows Subsystem for Linux.

When running the application, Visual Studio uses an ssh connection to localhost to run cmake -DCMAKE_BUILD_TYPE="Debug" .. and make, then uses gdbserver to debug the application. This works fine for my application's own code, including breakpoints and line-by-line debugging.

This application links to a library file, libhypro.so.17.09, which is also part of a CMake project. This library is also built locally (stored in my Windows file system, built within Linux through the /mnt/c/ mount, just as the main application) in debug mode. CMake did discover that dependency automatically.

I'm having trouble debugging my calls to this library. For example, if I break just before a call to library code and choose to Step Into, this is where I end up:

screenshot from Visual Studio

Note that

  • the Call Stack has disappeared, showing [Unknown/Just-In-Time compiled code] instead,
  • I'm inside an unhandled exception (which I'd expect to hit eventually, but certainly not immediately after a Step Into) and
  • the Modules window indicates that no symbols are available.

In addition, I did set a breakpoint in the library's code, and Visual Studio (correctly) asserts that “the breakpoint will not currently be hit”. Also, Debug output prints Loaded '/mnt/c/Users/felix/git/hypro/build/libhypro.so.17.09'. Cannot find or open the symbol file.

I'm relatively certain that libhypro.so.17.09 does include debug symbols as nm -gC libhypro.so prints a lot of output.

My case appears to be similar to this question but I'm not specifying the library's path manually, it's discovered by CMake.

Why are gdb and, in turn, Visual Studio failing to debug the library's code?

Solution

  • If you are debugging in gdbserver mode, the default, try switching to gdb mode in the project properties / debugging page.

    Basically, gdbserver mode is a nice idea that never quite delivered. Here's one discussion about it on the VCLinux GitHub site. As you'll see, gdb will become the default debugging mode once they've fixed the problems with console applications.