On Mon, 2023-05-29 at 17:16 -0300, Alexandre Oliva via Gcc wrote: > On May 17, 2023, Arsen Arsenović <ar...@aarsen.me> wrote: > > > ISTR Alexandre Oliva (CC added) mentioning leveraging GDB to > > implement various bits of LSP functionality, such as handling > > multiple TUs. > > I recall advancing that suggestion, reasoning that GDB was capable of > combining information from multiple translation units and of > reloading debug information, which GCC doesn't.
I'm not sure this will work well. The information LSP servers need is quite a bit more detailed (I believe) than what is found in the object file debug sections. Typically LSP servers generate their own index files, which are completely separate from any compiler-generated output. When the server starts it will proceed to parse and index the entire codebase (which is unfortunately slow) then they try to keep that index updated over time as code changes. So the LSP server will use the compiler front-end to parse the code and keep information about symbols and locations separately. LSP servers are not intended to be limited to dealing with the code that has already been compiled: not only do you want to be able to edit code before it's been compiled, but you want to be able to query new code as it's written in the editor, before it's even saved to disk. I recommend that anyone who is interested in this project, examine the LSP spec to understand what information the server needs to deal with: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/
