search

pocco81 / dap-buddy.nvim

🐞 Debug Adapter Protocol manager for Neovim
GNU General Public License v3.0
400 stars 48 forks source link

Can you add support for vscode-cpptools? #4

Closed pittcat closed 3 years ago

pittcat commented 3 years ago

I configured lldb-vscode, and found that lldb-vscode is a half-baked plan for cpp debug. When adding runInTerminal = true option into configuration, the following error info will be reported. Error info: Timed out trying to get messages from the debug adaptor If remove the option, nvim-dap is able to work properly. On the other hand, more linux user may choose gdb rather than lldb. Other people also encountered a related problem in https://github.com/mfussenegger/nvim-dap/issues/202

mfussenegger commented 3 years ago

Regarding the timed out error: May be worth trying again with the latest nvim-dap master. There were some issues with the environment options not being passed on correctly when opening the internal terminal.

pittcat commented 3 years ago

@mfussenegger I have tried the latest nvim-dap, but the bug still exists.

pocco81 commented 3 years ago

@pittcat done. However, I don't think I'll be merging it with main until somebody tests it first. If you or anybody else would like to test it: update to latest dev branch, install the debugger (:DIInstall ccppr_vsc_dbg) and add this helper function mentioned on their wiki, and then report back how it went.

Maybe I should include an option to create helper functions for certain debuggers like this one?

pittcat commented 3 years ago

I just tested the dev branch. Here is my configution about nvim-dap and DAPInstall.nvim.

local M = {}
local last_gdb_config
M.start_c_debugger = function(args, mi_mode, mi_debugger_path)
    local dap = require "dap"
    if args and #args > 0 then
        last_gdb_config = {
            type = "cpp",
            name = args[1],
            request = "launch",
            program = table.remove(args, 1),
            args = args,
            cwd = vim.fn.getcwd(),
            externalConsole = true,
            MIMode = "gdb",
            MIDebuggerPath = "/usr/bin/gdb"
          }
    end

    if not last_gdb_config then
        print('No binary to debug set! Use ":DebugC <binary> <args>" or ":DebugRust <binary> <args>"')
        return
    end

    dap.run(last_gdb_config)
    dap.repl.open()
end
return M

local dap_install = require("dap-install")

dap_install.setup({
    installation_path = "/tmp/test_dap_install/",
    verbosely_call_debuggers = true,
})

But cppdbg seems no effect.

pittcat commented 3 years ago

https://asciinema.org/a/VFTdeJvRxAw7GcOB4M33oLROo

pittcat commented 3 years ago

@mfussenegger @Pocco81 I have tried install cppdbg by vimspector. Configution is as same as cookbook. After i renamed cppdbg.ad7Engine.json to nvim-dap.ad7Engine.json, cppdbg can be activated. But at same time, an error occurred. Error info:

Stopping due to fatal error: JsonSerializationException: Cannot deserialize the current JSON array (e.g. [1,2,3]) into type 'Microsoft.VisualStudio.Shared.VSCodeDebugProtocol.Messages.ThreadsArguments' because the type requires a JSON object (e.g. {"name":"value"}) to deserialize correctly.
To fix this error either change the JSON to a JSON object (e.g. {"name":"value"}) or change the deserialized type to an array or a type that implements a collection interface (e.g. ICollection, IList) like List<T> that can be deserialized from a JSON array. JsonArrayAttribute can also be added to the type to force it to deserialize from a JSON array.
Path ''.
pittcat commented 3 years ago

I also tried cppdbg with vimspector, and i found that cppdbg was able to work well with vimspector. The bug only exists on nvim-dap client.

mfussenegger commented 3 years ago

Probably because it serializes an empty table {} as array instead of as dictionary (would require vim.empty_dict().

Could you post the last couple of log entries before you receive that error? That might give some indication of what property is serialized incorrectly.

pittcat commented 3 years ago

Is it these logs?

=thread-group-added,id="i1"
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=cmd-param-changed,param="pagination",value="off"

Stopped due to shared library event (no libraries added or removed)

Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.

Breakpoint 1, main () at dap_cppdbg_test.cpp:9

9     x = -10.23;

Loaded '/usr/lib/libstdc++.so.6'. Symbols loaded.

Loaded '/usr/lib/libm.so.6'. Symbols loaded.

Loaded '/usr/lib/libgcc_s.so.1'. Symbols loaded.

Loaded '/usr/lib/libc.so.6'. Symbols loaded.

Breakpoint 2, main () at dap_cppdbg_test.cpp:10

10    cout << "sin(" << x << "): " << sin(x) << endl;

Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)

Stopping due to fatal error: JsonSerializationException: Cannot deserialize the current JSON array (e.g. [1,2,3]) into type 'Microsoft.VisualStudio.Shared.VSCodeDebugProtocol.Messages.ThreadsArguments' because the type requires a JSON object (e.g. {"name":"value"}) to deserialize correctly.
To fix this error either change the JSON to a JSON object (e.g. {"name":"value"}) or change the deserialized type to an array or a type that implements a collection interface (e.g. ICollection, IList) like List<T> that can be deserialized from a JSON array. JsonArrayAttribute can also be added to the type to force it to deserialize from a JSON array.
Path ''.
mfussenegger commented 3 years ago

Is it these logs?

The nvim-dap logs, see :help dap.set_log_level().

I got it working without errors:

https://user-images.githubusercontent.com/38700/121674801-cdc28980-cab2-11eb-9b8c-1190f4bbc868.mp4

Adapter definition:

  dap.adapters.cpptools = {
    type = 'executable',
    command = HOME .. '/workspace/tmp/cpptools-linux/extension/debugAdapters/OpenDebugAD7',
  }

Additional configuration entry:

    {
      name = "Launch (vscode-cpptools)",
      type = "cpptools",
      request = "launch",
      program = function()
        return vim.fn.input('Path to executable: ', vim.fn.getcwd() .. '/', 'file')
      end,
      cwd = '${workspaceFolder}',
      stopOnEntry = true,
    },

I installed vscode-cpptools using:

(fyi @Pocco81 looks like the PR downloads the ARM64 version? The custom function is btw. not necessary and the attach property in the adapter definition isn't supported/used by nvim-dap )

mfussenegger commented 3 years ago

Btw, doing a github code search for ThreadsArguments I suspect the error is caused by the threads request, but that would indicate a debug adapter bug, because the arguments to the threads request can be absent according to the debug adapter protocol specification and nvim-dap doesn't send any.

If you want to try out if this suspicion is correct, you could try this patch in nvim-dap:

diff --git a/lua/dap/session.lua b/lua/dap/session.lua
index b1a0ad5..e367b37 100644
--- a/lua/dap/session.lua
+++ b/lua/dap/session.lua
@@ -256,11 +256,11 @@ function Session:event_stopped(stopped)
     self:request('continue', { threadId = stopped.threadId })
     return
   end
   progress.report('Thread stopped: ' .. stopped.threadId)
   self.stopped_thread_id = stopped.threadId
-  self:request('threads', nil, function(err0, threads_resp)
+  self:request('threads', {}, function(err0, threads_resp)
     if err0 then
       print('Error retrieving threads: ' .. err0.message)
       return
     end
     local threads = {}

Update: If I apply this, it no longer stops at the breakpoint and instead gets stuck and I get the error you posted in the logs

Do you use any other nvim-dap related extension? Maybe another extension makes a threads request with a invalid arguments option.

Update2: Could be caused by nvim-dap-ui: https://github.com/rcarriga/nvim-dap-ui/blob/7564f9163b786af1a2bb251385d634ef860d5d33/lua/dapui/elements/stacks.lua#L144 - are you using that?

pittcat commented 3 years ago

@mfussenegger Yes, I'm using nvim-dap-ui. After I disabled nvim-dap-ui, the error disappeared. Maybe I should open an issue on nvim-dap-ui.

pocco81 commented 3 years ago

@mfussenegger since your installation method worked, could you PR that?

mfussenegger commented 3 years ago

@pittcat fyi regarding the lldb-vscode runInTerminal = true issue - that might be related to https://github.com/mfussenegger/nvim-dap/issues/210

@Pocco81 No sorry

pocco81 commented 3 years ago

@mfussenegger no worries, I'll implement it myself then :+1:

pocco81 commented 3 years ago

Done. Thanks @mfussenegger! I added it as "experimental".

nyngwang commented 1 year ago

@pittcat What do you mean:

[...] I configured lldb-vscode, and found that lldb-vscode is a half-baked plan for cpp debug. [...]

?

update: Nevermind, I just realized that lldb-vscode and codelldb are two different things. I'm using the later and my question was about why you said its half-baked.