I want to learn about clangd source code. But I don’t use how to use gdb to debug clangd? Should I use gdb to attach clangd thread to debug?
I started working with clangd a while ago, so I can maybe answer that from a newcomer’s perspective: The answer to your question depends on which part of clangd you want to investigate. For me, the easiest way to get started was to run
clangd --check on a specific file and set a breakpoint at the functionality that I wanted to understand - in my case inlay hints. This may require that you add a feature to
clangd --check that runs the specific feature you want to understand. An alternative would be running the unit tests and again setting breakpoints. I can’t say too much about attaching to running processes, but that may cause issues, because some IDE integrations don’t like it if LSP requrests time out.
Also definitely check out the LLVM pretty-printers for containers and, most importantly, the
dump() function that is available on almost all important AST types.
Thank you very much. I have an another question, can I directly use
clangd --check to run test file under
No, the unit tests are a standalone binary, you don’t need to run
clangd on them. They are not compiled by default though, IIRC, so you need to run
make ClangdTests or
ninja ClangdTests (depending on your build system of choice) and then run the binary this creates. You can filter which tests are run by the
One approach I’ve taken to debug clangd as driven by a client such as vscode is to use the “record and replay” debugger at https://rr-project.org/. Note, this only works on Linux.
To do this, I write a wrapper script
clangd-rr which runs
rr record clangd, and point my editor to it (e.g. via
"clangd.path" in vscode).
Then I run my editor, reproduce the issue, and close my editor.
Finally, I run
rr replay, which opens gdb and lets me debug the recording (with the very significant added bonus that I can
reverse-continue to a breakpoint or a watchpoint since I’m debugging a recording rather than a live program).