dap-gdb-lldb apparently requires nodejs

[ville-h]

It would seem that dap-gdb-lldb requires nodejs. Choosing the option to not to call dap-gdb-lldb-setup as per documentation, but rather downloading it manually, and then calling dap-debug, selecting a configuration then results in an error:

dap--create-session: Searching for program: No such file or directory, node

I spent a better part of the day trying to verify I was not screwing things up on my own with out realizing the word "node" was the operational word here and that it refers to "nodejs" specifically. That sentence simply looked like a bug and one that was cut-off or otherwise malformed. I think it's due to the use of "," rather than ":" to me and even better would be to have ' or " around it.

For the benefit of us out-of-touch people who haven't done web development since turn of the millennium it would be nice to see:

• documentation saying that this requires "nodejs" to be installed on the system
• the error message explicitly says "nodejs" rather than "node". The word "node" does not automatically mean "nodejs" to me at least
• explicitly point out that the .vsix file is a zip file in disguise and can be extracted with unzip

Also isn't there a truly "native" option to debug c and c++ with out having to download visual studio code extensions and installing nodejs? Does relying on nodejs mean the tooling is relying on npm and thus that the development tools I rely on the most have the chance of getting broken by it? If I rely on this package is my ability to debug my programs going to depend on what happens in npm? What part is missing that it was decided that visual studio code extensions and nodejs are required? Like I said I don't do web development so I've no clear understanding how this ecosystem functions and what kind of impact any shenanigans in npm would have on my ability to do my tasks.

[yyoncho]

Thank you for the feedback.

Also isn't there a truly "native" option to debug c and c++ with out having to download visual studio code extensions and installing nodejs?

1. I Generally recommend cpptools debug adapter. It is binary and it has mono dependency. It still downloads binary from github.
2. lldb-vscode is binary distributed by lldb team.
3. I know that vscode-lldb is good too - but I haven't tested it, it was recently added.

IMHO stay out of dap-gdb-lldb adapter. It has a lot of limitations.

Does relying on nodejs mean the tooling is relying on npm and thus that the development tools I rely on the most have the chance of getting broken by it? If I rely on this package is my ability to debug my programs going to depend on what happens in npm?

I don't have an answer to these questions.

What part is missing that it was decided that visual studio code extensions and nodejs are required?

dap-mode is just a client and we don't control how the adapters are implemented. We do our best effort to expose the dap functionality.

[yyoncho]

You may check https://emacs-lsp.github.io/lsp-mode/tutorials/CPP-guide/ it has some notes about debugger setup.

[ville-h]

2. lldb-vscode is binary distributed by lldb team.

Ok this sounds promissing. In theory I should be able to install my distro's package for lldb with out requiring actual visual studio code extensions? Looking at the documentation it would seem so. I've:

(require 'dap-mode)
(require 'dap-lldb)

in my init.el and then running dap-debug selecting "LLDB (VS Code) :: Run Configuration" results in:

dap--send-message: Process LLDB::Run not running Debug session process exited with status: exited abnormally with code 127

So not entirely sure what else should I have set up? I can see both lldb-server and lldb-vscode are in my $PATH.

[yyoncho]

So not entirely sure what else should I have set up? I can see both lldb-server and lldb-vscode are in my $PATH.

Can you check the content of stderr buffer?

[ville-h]

emacs: /home/ville/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin/lldb-vscode: No such file or directory

Process LLDB::Run stderr finished

So it would seem even that is expecting some kind of visual studio code extension to function? Or it's just not looking for lldb-vscode from $PATH for some reason?

[yyoncho]

Hm, afaics the default is under ~/.vscode/extensions, maybe @danielmartin can explain why the default is not poiting to lldb-vscode assuming that it is on the path.

@ville-h I guess something like

(setq dap-lldb-debug-program `("lldb-vscode"))

should be enough for you.

[ville-h]

Ok thanks. That does work for me at least once I add a template like so:

(dap-register-debug-template "lldb-vscode" (list
    :type "lldb-vscode"
    :cwd "/home/ville/projects/test/"
    :request "launch"
    :program "/home/ville/projects/test/xxx"
))

Should the default template ask me to set some of these values? It fails with a "*Warnings*" buffer containing:

Warning (emacs): Initialize request failed: Could not create a target for a program '/home/ville/projects/test/src/main.c': '/home/ville/projects/test/src/main.c' doesn't contain any 'host' platform architectures: x86_64, i386.

I also tried the dumbest-possible way:

mkdir -p ~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin/
ln -s /usr/bin/lldb-vscode ~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin/

and that works out as well with the above template. But hey at least there is a way to debug that does not involve visual studio code extensions and nodejs!

[yyoncho]

Should the default template ask me to set some of these values?

dap-lldb-debugged-program-function is configurable and defaults to the current buffer, you can change it to whatever you want. dap-lldb.el is pretty basic but it provides the building blocks and together with dap core files is should allow creating the experience that fits your needs(at least I hope so).

I personally use dap-debug calls with an already populated template.

[yyoncho]

I personally use dap-debug calls with an already populated template.

in combination with dap-debug-last which makes the picking of the template less important.

[ville-h]

Also placing a "launch.json" at the project root works:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "debug xxx",
            "type": "lldb-vscode",
            "request": "launch",
            "program": "${workspaceFolder}/xxx",
            "args": [],
            "cwd": "${workspaceFolder}"
        }
    ]
}

This possibility could also have a better visibility in the documentation.

[danielmartin]

Ivan Yonchovski notifications@github.com writes:

Hm, afaics default is pointing to lldb-vscode binary, but the default is under ~/.vscode/extensions, maybe @danielmartin can explain why default is not poiting to lldb-vscode assuming that it is on the path.

I followed the same default path as in the instructions that are in the LLVM monorepo: https://github.com/llvm/llvm-project/tree/main/lldb/tools/lldb-vscode

It's possible that nowadays the debugger extension is already installed by package managers and present in PATH by default. If that's the case, we can change the default to simply point to lldb-vscode.

I can change the default if you all agree.

[ville-h]

It's possible that nowadays the debugger extension is already installed by package managers and present in PATH by default

lldb-vscode is installed by default by the lldb package on arch linux at least.

[reenigneEsrever92]

On Fedora, too. I guess.

[daym]

On Guix, lldb-vscode is installed (and findable by PATH) by default, too. And Guix doesn't change upstream packages if it can be helped. So I think it will be the same for any distribution.