Support of pipeTransport

[daniel-brosche]

In the general Cpp-Extension there is a possiblity to configure a so called pipeTransport as part of a launch configuration.
Over this way it is possible for example to pipe through ssh, that is quite helpful for debugging embeeded devices.

Furthermore it is possible to pipe directly through in a docker environment.
Therefore no server is needed just a locally installed lldb.

[vadimcn]

Please see Remote Debugging. You can configure lldb-server to use a pipe connection as well as tcp.

[daniel-brosche]

Good to know, but I can't find in extensive documentation how to do that.
Could you please give me a hint or an example configuration would be great.
With the Cpp-Extension vscode can pipe directly to the gdb on the remote system.
As you described, it seems there is still the server counter-part involved?

[vadimcn]

I haven't done that myself. Here's some docs on lldb site: https://lldb.llvm.org/man/lldb-server.html.

As you described, it seems there is still the server counter-part involved?

Yes. I think in the case of Cpp-Extension, gdb runs inside the container too?

[daniel-brosche]

Yes. I think in the case of Cpp-Extension, gdb runs inside the container too?

Exactly, the Cpp-Extension only needs a GDB installed on the target system, no extra gdbserver is needed for that.
The extension SSH directly to the target system and starts the gdb there. All interactions with the gdb are piped from the host to the target.

[vadimcn]

Codelldb doesn't work like that. The closest analogue would be installing lldb-server in the target container/device and running a remote debugging session.

[daniel-brosche]

Is it possible to configure the lldb-path? Maybe in first attemp I could try to wrap all lldb calls through a ssh-helper script. As long as the paths from host and target are the same it might work.

[vadimcn]

In the case of cppdbg's pipe transport, you are actually using gdb that is a part of the docker image, which cppdbg adapter communicates with over the pipe using "gbd-mi" protocol. CodeLLDB loads LLDB shared library in-process and uses its API directly, so this sort of remoting is not possible.

[daniel-brosche]

I understand... I have played around with the vscode-remote extension and lldb as part of the remote extensions. As long as the target system has enough resources I could directly debug with ssh and the installed lldb on the target system. Unfortunately for small embedded devices this is not an option.

[vadimcn]

for small embedded devices this is not an option.

Those, are exactly what remote debugging exists for...

[daniel-brosche]

I have noticed that alot of debug symbols are downloaded from the target device to the host which leads to slowdown of the debug-session. Is there an option to optimize debug symbol handling?

[vadimcn]

Is there an option to optimize debug symbol handling?

See here. LLDB is pulling remote files because it doesn't know where to find a local copy.

[daniel-brosche]

I have sysroot where basically all needed files are there, but unfortunately it don't seems to specifiy to load from the sysroot and therefore the most files are pulled from the remote e.g.:

/home/user/.lldb/module_cache/remote-linux/.cache/DB2CAEEE-C374-82A9-8AB1-416D0A9AFE29-44930DE9/libdl.so.2 

I have tried to specify sysroot as follows as part of the initCommands:

"platform select --sysroot /opt/x86_64-lenze-linux-gnu/sysroot remote-linux",

I have found something interessting in lldb documentation regarding the --no-dependents option

We use the --no-dependents flag with the target create command so that we don’t load all of the dependent shared libraries from the current system. When we symbolicate, we are often symbolicating a binary that was running on another system, and even though the main executable might reference shared libraries in /usr/lib, we often don’t want to load the versions on the current computer.

How can I properly configure this option?

[vadimcn]

Honestly, I don't have that much experience with remote debugging. When I do, I always cross-compile, so I just let LLDB upload local binary to the target and run it there. It's quite likely that some enhancements could be made in codelldb to make remote debugging more ergonomic, but I am not sure what those would be (some sort of mapping between local<->remote files?). If you figure it out, please let me know!

How can I properly configure this option?

I am not aiming to wrap every possible debugging scenario that LLDB supports in VSCode UI/settings, just the basics. For everything else, there's the Custom Launch mode. This should allow you to set it up exactly the way you need.

[daniel-brosche]

I have noticed that many of the symbols are resolved by specifying the --sysroot directory as described above.
Additionally I was able to specify more host directories which should be used to load debug symbols.

 "settings append target.exec-search-paths /home/user/git/my_project/build/dist/lib/",
 "settings append target.exec-search-paths /home/user/git/my_project/build/dist/lib/plugins",

For some reasons there are still a small amount of shared objects which will be downloaded from the target although these files are part of the sysroot.

I will try to experiment with the custom launch mode.