How should I use gdb to debug clangd?

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 unittests?

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 --gtest_filter=SomeTestName*with*wildcards

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 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).