lldb-vscode showing assembly instructions

[astahjmo]

I'm trying to use nvim-dap to debug C code using lldb-vscode (I was using gdb with nvim termdebug but yes, I'm trying something new) and whatever I do, dap shows the instructions in assembly instead of my source code

my nvim-dap config: (default config)

dap.adapters.lldb = {
  type = 'executable',
  command = '/usr/bin/lldb-vscode', -- adjust as needed, must be absolute path
  name = 'lldb'
}
dap.listeners.before.event_initialized["split_winow"] = function()
	vim.cmd("vs")
end
dap.configurations.c = {
  {
    name = 'Launch',
    type = 'lldb',
    request = 'launch',
    program = function()
      return vim.fn.input('Path to executable: ', vim.fn.getcwd() .. '/', 'file')
    end,
    cwd = '${workspaceFolder}',
    stopOnEntry = true,
    args = {},

    -- 💀
    -- if you change `runInTerminal` to true, you might need to change the yama/ptrace_scope setting:
    --
    --    echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
    --
    -- Otherwise you might get the following error:
    --
    --    Error on launch: Failed to attach to the target process
    --
    -- But you should be aware of the implications:
    -- https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html
    -- runInTerminal = false,
  },
}

How can I solve this? I want nvim-dap to stop showing me instructions in assembly so I can debug my C code and get to normally use nvim-dap

[krishnakumarg1984]

I have literally the same issue, except that the assembly code is shown when trying to step past the final return statement in main() in a C++ program!

This problem does not happen with cpptools, but only occurs with codelldb.

[igorlfs]

I've noticed the same happens with me, so it's most likely a bug with CodeLLDB. Can you open an issue upstream? By the way, what's your use case to step out of main?

[krishnakumarg1984]

Really difficult to open a bug on upstream. Their notations/references in doc etc do not align with neovim or nvim-dap, but rather with VSCode.

[theHamsta]

I assume that you get normal source code with gdb? So you did compile with debug symbols?

[krishnakumarg1984]

Correct. Normal source code visually highlighted with cpptools (using gdb). Note we are talking about displaying disassembly after finishing main() whereas cpptools just quits debugging as expected. Yes, of course, compiled with debug symbols with the DWARF-5 format.

My compilation flags to g++ are: -pedantic-errors -pipe -std=c++20 -Wall -Wcast-align -Wcast-qual -Wconversion -Wctor-dtor-privacy -Wdeprecated-copy-dtor -Wdouble-promotion -Wextra -Wextra-semi -Wfloat-equal -Wformat=2 -Wnull-dereference -Wold-style-cast -Woverloaded-virtual -Wpedantic -Wshadow -Wsign-conversion -Wsign-promo -Wstrict-aliasing -Wswitch-default -Wswitch-enum -Wundef -Wunused-macros -O0 -g -gdwarf-5 -fsanitize=address -fasynchronous-unwind-tables -fsanitize=float-cast-overflow -fsanitize=float-divide-by-zero -fsanitize=undefined -fstack-clash-protection -fstack-protector-all -fstack-protector-strong -fstrict-aliasing -DDEBUG

[wowonline]

I assume that you get normal source code with gdb? So you did compile with debug symbols?

I had the same issue as mentioned in topic but for vscode extension. The solution was to compile with -g. Now CodeLLDB in vscode iterates through source code instead of assembly code.

[krishnakumarg1984]

bump

[LiadOz]

I had a similar issue. I narrowed it down to being a problem with my lldb workflow, as this happened when I tried using lldb without nvim-dap. I suggest first trying to make if the issue lies with lldb or the debug adapter by just running it with lldb.
The issue I had was due to a lldb not able to figure out where the source code is, I fixed it by changing the source maps. Here is the launch.json

{
   "version": "0.2.0",
   "configurations": [
       {
           "type": "cppdbg",
           "request": "launch",
           "name": "lldb attach to running remote process",
           "program": "${workspaceFolder}/a.out",
           "cwd": "${workspaceFolder}",
           "targetArchitecture": "x86_64",
           "MIMode": "lldb",
           "customLaunchSetupCommands": [
               {"text": "settings append target.source-map /root/test ${workspaceFolder}", "description": "source paths"},
               {"text": "platform select remote-linux", "description": "select platform"},
               {"text": "platform connect connect://my-remote-server:1337", "description":  "connect to remote"},
               {"text": "platform process attach --pid 12466", "description": "attach to process"}
           ],
           "launchCompleteCommand": "None"
       }
   ]
}

As you can see this configuration is for remote debugging with lldb server so most of the stuff can be ignored, the important point here is calling settings append target.source-map /root/test ${workspaceFolder} after the lldb instance is launched (this should be tested before trying to use the debug adapter). There should be a smiliar option for customLaunchSetupCommands in lldb-vscode. The binary was compiled on the remote vm in /root/test that's why I needed to remap the sources. In order to find out what the original directory is I ran image lookup -vn main and got CompileUnit: id = {0x00000000}, file = "/root/test/app.c", language = "c89"