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:
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?