How to setup lldb-vscode.exe lldb-server.exe lldb.exe with CodeLite(Debug Adapter Client)?
And can I use dgb with llvm clang? ( I tried E:/msys64/clang64/bin/gdb.exe, but it did not work, no errors)
I don’t have time to try this myself today, but my guess is that the Command the debug adapter server execution command line isn’t just the path to the DAP server executable. It’s the whole command used to run it, including options.
So it may need to be like lldb-vscode.exe -p 4711, that is if we assume that Connection string is what the debugger uses to connect to the DAP server, not something it uses when starting the server.
See lldb-vscode.exe --help for the details of -p.
So try keeping Connection String as is, and adding a -p option to Command.
And FYI, if you see lldb-dap, this is the same tool as lldb-vscode. We recently renamed it, the functionality is the same. Just in case you’re looking at very recent documentation in lldb.
Otherwise, @wallace may have some input also as Code Owner for lldb-dap as it’s now known.
This isn’t the cause of the error window I expect but I assume it would be /lldb.exe if anything.
I modified the command, there is no error now, it looks like the debugger starts, but it closes after lens than half a sec, it is supposed to just close?, there is a breakpoint too. The debug interface that stays for less than half a second:
Potentially lldb-vscode is exiting because it doesn’t understand whatever it’s been given by the IDE. Impossible to say without logs.
If you are on Linux you may be able to strace the IDE itself and see where it calls out to lldb-vscode, then replicate that on a command line to check that the options are valid.
You could also try starting lldb-vscode manually, then leaving the command setting in the IDE blank. To maybe trick it into connecting to an existing instance. Then you can work out the correct options and see any messages lldb-vscode prints.
Beyond that, I suggest you take this up at Issues · eranif/codelite · GitHub. I see [Bug]: Debugger time out error - Failed to connect to DAP server · Issue #3218 · eranif/codelite · GitHub for example, though it only covers what we’ve already talked about.
And while you’re raising issues, the content in Debug Adapter Client (dap) - CodeLite Documentation could do with additions to say what program uses each setting and what for.
My mistake, of course you’re on Windows. Maybe you can catch the invocation in task manager somehow? This is outside my area of expertise.
What I got:
CodeLite 17.0.0 - Stable released on January 11, 2023
LLVM Clang 17.0.3
https://github.com/llvm/llvm-project/releases/download/llvmorg-17.0.3/LLVM-17.0.3-win64.exe
MSYS2 Clang
https://github.com/msys2/msys2-installer/releases/download/2023-10-26/msys2-x86_64-20231026.exe
(from MSYS2 ) (and used Windows - CodeLite Documentation )
pacman -Sy git \
openssh \
mingw-w64-clang-x86_64-gdb \
mingw-w64-clang-x86_64-toolchain \
mingw-w64-clang-x86_64-python3 \
mingw-w64-clang-x86_64-cmake \
mingw-w64-clang-x86_64-libffi \
mingw-w64-clang-x86_64-jq \
mingw-w64-clang-x86_64-libxml2 \
unzip
Codelite settings:
MakeFile Generator: CodeLite Makefile Generator
Compiler gcc-17.0.2(clang msys64)
Modified by MakeFile Generator:
Output File: $(ProjectName).exe
Executable to Run/Debug: $(WorkspacePath)/build-$(WorkspaceConfiguration)/bin/$(OutputFile)
Working Directory: $(WorkspacePath)/build-$(WorkspaceConfiguration)/lib
Debug Adapter Client:
Command: E:\CodeLite\LLDB_cpptools-win64\extension\debugAdapters\bin\OpenDebugAD7.exe --server (edit)
E:\CodeLite\compilar\msys64-clang\clang64\bin\lldb-vscode.exe -p 4711
Connection string: tcp://127.0.0.1:4711
If I compile ‘hello world’ example with:
MakeFile Generator: CodeLite Makefile Generator
Compiler: gcc-17.0.2(clang msys64)
Both GNU DBG and Debug Adapter Client work normaly.
Build Output:
E:/CodeLite/compilar/msys64-clang/clang64/bin/mingw32-make.exe -j16 -e -f Makefile
"----------Building project:[ test - Debug ]----------"
mingw32-make[1]: Entering directory 'E:/CodeLite/proiecte/test'
E:/CodeLite/compilar/msys64-clang/clang64/bin/g++.exe -c "E:/CodeLite/proiecte/test/main.cpp" -gdwarf-2 -fstandalone-debug -O0 -Wall -o ../build-Debug/test/main.cpp.o -I. -I.
E:/CodeLite/compilar/msys64-clang/clang64/bin/g++.exe -o ..\build-Debug\bin\test.exe @../build-Debug/test/ObjectsList.txt -L.
mingw32-make[1]: Leaving directory 'E:/CodeLite/proiecte/test'
=== build completed successfully (0 errors, 0 warnings) ===
If I compile ‘hello world’ example with:
MakeFile Generator: CodeLite Makefile Generator
Compiler: gcc-17.0.3(clang llvm)
No debugger works.
GNU DGB: nothing happens
Debug Adapter Client: The debug interface that stays for less than half a second
(using DAP: Adding ‘std::system(“pause”);’ the debug interface does not close, Continue does nothing, Stop works, Next does nothing, Pause works and Next works in Assembly. Breakpoints Appear in the list but are not respected)
Build Output:
E:/CodeLite/compilar/msys64-clang/clang64/bin/mingw32-make.exe -j16 -e -f Makefile
"----------Building project:[ test - Debug ]----------"
mingw32-make[1]: Entering directory 'E:/CodeLite/proiecte/test'
E:/CodeLite/compilar/LLVM-17.0.3-Clang/bin/clang++.exe -c "E:/CodeLite/proiecte/test/main.cpp" -m64 -g -O0 -gdwarf-2 -Wall -fstandalone-debug -o ../build-Debug/test/main.cpp.o -I. -I.
E:/CodeLite/compilar/LLVM-17.0.3-Clang/bin/clang++.exe -o ..\build-Debug\bin\test.exe @../build-Debug/test/ObjectsList.txt -L.
mingw32-make[1]: Leaving directory 'E:/CodeLite/proiecte/test'
=== build completed successfully (0 errors, 0 warnings) ===
So with msys2 clang/g++ , GNU DBG and DAP works, but not with LLVM Clang.
LLVM Clang does not come with make(or is named something else?) and I use ‘mingw32-make.exe -j16’ from msys2 clang, is this a problem?
Do I need to pass something else to the compiler to make debugger working?
The only advice I can give at this point is to pass the environment variable LLDBDAP_LOG to the debug adapter with a path to a file where you can inspect the entire DAP transactions and compare it with VSCode’s. It might help you identify if a certain message or request is needed for it to work.
Is the exe output from clang++.exe(clang++.exe -g main.cpp -o test3.exe -lstdc++) supposed to work with gdb?
I get “No debugging symbols found in test3/test3.exe”
(clang++.exe creates test3.pdb and test3.ilk and 1mb test3.exe)
(g++.exe -g main.cpp -o test2.exe -lstdc++, creates 160kb test2.exe only and works in gdb, same main.cpp)
I saw in a post from Jan 2022: Gdb < 10.1 can't read clang's DWARF v5
$ cat test.c
int main() { return 0; }
$ clang test.c -g -o test
gdb test
(he used gdb 10, I used 13)( I thought to use [LLVM 13.0.1] dated Jan 2022)
I used the same comands(clang.exe or clang++), I still get “No debugging symbols found in test3.exe” .
clang.exe or clang++ still generate test3.ilk and test3.pdb
Other things I found:
Bring on the Bugs!
So this is where you come in. We’ve tested simple debugging scenarios with our PDBs, but we still consider this alpha in terms of debug info quality. We’d love for you to try it out and report issues on our bug tracker. To get you started, download the latest snapshot of clang for Windows. Here are two simple ways to test out this new functionality:
Have clang-cl invoke lld automatically
clang-cl -fuse-ld=lld -Z7 -MTd hello.cpp
Invoke clang-cl and lld separately.
clang-cl -c -Z7 -MTd -o hello.obj hello.cpp
lld-link -debug hello.obj
We look forward to the onslaught of bug reports!
I tried different parameters -ggdb , -gdwarf-4
I don’t know how to not generate pdb files, maybe this is the problem.