Vscode-cpptools: show std::string as string during debugging

[agauniyal]

Currently std::string variables are shown as STL containers, but it would be quite beneficial if we could see actual contents as well, either during hovering over that var or by putting it at watch.

[jhasse]

Assuming you're using GDB, this is a duplicate of #69. Typing -exec -enable-pretty-printing in the debug console will show the content of strings, but it's disabled by default for performance reasons.

I haven't had any problems with it enabled though, maybe the default can be changed?

[renkun-ken]

@jhasse, I tried -exec -enable-pretty-printing and it seems only to work with containers (e.g. vector<T>), a std::string is always shown as <incomplete type> in debugging.

[jhasse]

Hm ... works for me on Fedora Linux 24:

[MikaelSmith]

The -exec -enable-pretty-printing option seems unsupported in lldb.

[misuo]

Yes, confirmed @MikaelSmith. On Max OS X - using the LLDB - the debugger console outputs:

-exec -enable-pretty-printing 

result-class: done
supported: 0

So it doesn't seem to be supported.

The VARIABLES window section do show content but it pretty much useless to use for complex Standard C++ library types, such as std::string. Right now I'm using old fashioned "print" (aka std::cout) for debugging.

[agauniyal]

Atleast provide a nice button or some config option to turn this on by default..

[jhasse]

Please just turn it on by default, no button. Everyone who wants to turn this off, should be in the minority.

[delmyers]

@jhasse we made the determination to turn this off by default because we were seeing some large performace problems due to pretty printing. We aren't in a place where we would want to risk perf in order to show this kind of data. Also, it only works on gdb for linux. LLDB, mingw, and Cygwin do not have support for pretty printing. We are looking at other solutions that will work for both lldb and gdb without the need for pretty printing.

[jhasse]

we made the determination to turn this off by default because we were seeing some large performace problems due to pretty printing

When did you notice this? Maybe it's possible to fix this in GDB.

Also, it only works on gdb for linux. LLDB, mingw, and Cygwin do not have support for pretty printing.

MinGW definitely has support for pretty printing!

#include <iostream>
#include <string>
#include <vector>

int main() {
    std::vector<int> bar{1, 2, 3, 4, 5, 6};
    std::string foo = "Hello ";
    foo += "World";
    std::cout << foo << std::endl;
}

I don't know much about LLDB, but if I understand it correctly, it also supports pretty printing, but names it differently: http://lldb.llvm.org/varformats.html

[TurboTim]

+1 VSCode needs this support _urgently_, one of the main reasons I choose VS over Sublime etc is due to the debugging, which is currently rendered almost useless by this missing feature.

Cheers
Tim

[TurboTim]

Also, fair enough don't have it on by default, but certainly allow us to override it in launch.json/c_cpp_properties.json

[TurboTim]

-exec p <whatever> in the debug window uses your GDB pretty printers like normal as a work around I have just discovered

[crioux]

Here is a terrible sad hack to make this work with LLDB on OSX.
First, back up ~/.vscode/extensions/ms-vscode.cpptools-0.9.2/debugAdapters/lldb (or whichever version you're running.
Then:

cd ~/.vscode/extensions/ms-vscode.cpptools-0.9.2/debugAdapters/lldb/bin
rm debugserver
rm lldb-argdumper
rm lldb-mi
ln -s /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver
ln -s /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/lldb-argdumper
ln -s /Applications/Xcode.app/Contents/Developer/usr/bin/lldb-mi

This will force vscode to use the XCode version of lldb rather than the bundled LLDB, which is built without the ability to do 'command script import', and without the libcxx.py needed to parse the stl structures properly. Anyway, hope that helps someone. (this was tested on Sierra and latest XCode only)

[TurboTim]

Excellent! This, to me, shows that the bundled version should be updated. Also, the fact we're having to hack around this, surely does show its a feature that is in demand.

Thanks crioux

[jacdavis]

The version of lldb that ships with xcode has numerous bugs in its mi implementation that we have fixed in the version we are distributing. Please keep in mind that by applying this hack, things are likely to get significantly less stable.

[pieandcakes]

If you want to enable pretty printing by default for gdb, you can add the following to your launch.json

"setupCommands": [ { "text": "-enable-pretty-printing" } ]

This will run the command for each debug session, eliminating the need to enter it each time.

HTH
-Pierson

[TurboTim]

Great, thanks!

Now we just need LLDB to be rebuilt with pretty printing support...

[pieandcakes]

@TurboTim That is something that we will take a look at. The dependency on Python is the sticking point.

[crioux]

One could bundle python and use this to point to bundled python:
(from http://lldb.llvm.org/build.html)

LLDB_RELOCATABLE_PYTHON (Default=0): When this is 0, LLDB will bind statically to the location specified in the PYTHON_HOME CMake variable, ignoring any value of PYTHONHOME set in the environment. This is most useful for developers who simply want to run LLDB after they build it. If you wish to move a build of LLDB to a different machine where Python will be in a different location, setting LLDB_RELOCATABLE_PYTHON to 1 will cause Python to use its default mechanism for finding the python installation at runtime (looking for installed Pythons, or using the PYTHONHOME environment variable if it is specified).

[pieandcakes]

The pretty printing for GDB is now enabled by default when creating a new launch.json. We also have support for .natvis files if people want to explore visualization that way too.

[malytskyy]

Hi,
@pieandcakes I wasn't able to find a way to specify more than one .NATVIS file. Is it supported? It would be great, especially if one has several custom NATVIS files

Thanks!

[delmyers]

@malytskyy, right now only one natvis file is supported. If you want to use multiple files, you will have to merge them into a single one.

We decided that we wanted to get the pretty printing stuff out asap, and then get feedback. So, this is useful feedback.

[pieandcakes]

@TurboTim As of version 0.10.0 of the extension, the lldb that is part of the extension is now compiled with Python enabled. We expect users to have a version of Python 2.7 to be installed locally on the Mac already since it comes with a default installation of OS X.

[jjimenezshaw]

@pieandcakes If I use "c++" as the compiler (from gcc), it works as expected. However, if I use "clang++", the strings display <incomplete type> in the watch panel.
Versions: Ubuntu 16.04, vscode 1.15.1, cpptools 0.12.4, c++ (compiler), 5.4.0, clang++ 3.8.0
Compilation command: "c++ -std=c++14 -g -pthread *.cpp" vs "clang++ -std=c++14 -g -pthread *.cpp"

Any missing option for clang?

[pieandcakes]

@jjimenezshaw I assume you are still using gdb to debug. I don't know if there are compatibility differences between compiler and debugger but we have only tested with gdb on Ubuntu.

[jjimenezshaw]

@pieandcakes Yes, I still use gdb. The only difference was the compiler.
How are the options to use lldb instead of gdb? Maybe it works.

[pieandcakes]

@jjimenezshaw Our lldb configuration is for OS X. Our extension provides slightly different commands when you change the MIMode to lldb to deal with the quirks of the lldb debugger. I know in your launch.json we enable gdb's pretty printing. Maybe because its compiled with clang++ that gdb isn't getting the right info for their pretty printer to handle it. you may try removing that block and see if that fixes the problem but you'll lose some visualization.

[jjimenezshaw]

I tried with MIMode: "lldb", and it works for std::string when compiling with clang++.
Thank you!
PS Not tested other features.

[OkkeHendriks]

I could get std::string to show up in the debugger (compiling with clang-5.0 debugging with gdb) when compiling with -D_GLIBCXX_DEBUG. See: https://stackoverflow.com/questions/41745527/cannot-view-stdstring-when-compiled-with-clang

[alexeyr]

A better workaround is -fno-limit-debug-info (see https://bugs.llvm.org/show_bug.cgi?id=24202#c9), because

The -D_GLIBCXX_DEBUG workaround is unacceptable: libstdc++ changes ABI when it is defined, and so linking with any other libstdc++-linked code (gtkmm in my case) causes a crash.

According to that thread, installing a -dbg/-dbgsym version of libstdc++ should work as well, but it didn't for me.