Fetching debuginfo and executable from debuginfod servers is currently supported in LLDB. I want to get feedback on the best way to integrate this so it can be used from the SBAPI.
The goal is to support resolving missing source files from either using the cli or the SBAPI.
There is a current draft that currently works from the cli here.
I also want to confirm, what is intended behaviour or is missing feature before adding tests and code cleanup.
For example the closest thing we have to resolving source file is setting source-maps if you try to get the SBLineEntry from the frame you get the source map entry but if you use the address you get the original entry.
(lldb) file main
(lldb) b main
(lldb) run
(lldb) settings set target.source-map /home/da-viper/Dev/projects/test_lldb/main.cpp /home/da-viper/Dev/projects/test_lldb/new/main.cpp
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> frame = lldb.target.process.selected_thread.selected_frame
>>> frame.addr
main`main + 8 at main.cpp:22:9
>>> frame.GetLineEntry()
/home/da-viper/Dev/projects/test_lldb/new/main.cpp:22:9
>>> frame.addr.GetLineEntry()
/home/da-viper/Dev/projects/test_lldb/main.cpp:22:9
Actually it won’t resolve it directly, because to apply source maps you need to have an SBTarget, but I added SBAddress::GetSymbolContext(SBTarget) function and calling GetLineEntry with this object should apply the source maps.
As part of Python callback for source file resolution, I have an implementation using SB API which works. PR1, PR2. The comment I got was to implement this using Scripting processes for symbol locator instead of SB API’s in SBPlatform. I was planning to get to it in the next few months if no one is looking into it yet
I wonder if the existing loading of files from local disk should also be moved behind the SourceLocator interface?
Are you planning to also wire this with the “source” request from the Debug Adapter protocol in lldb-dap? That way, clients such as VS-Code could directly display the source file in the IDE.
Are you planning to also wire this with the “source” request from the Debug Adapter protocol in lldb-dap?
Yes that is the plan, Its getting the correct interface and how to integrate it with the Scripting Bridge existing API functions that there is a little issue.
I wonder if the existing loading of files from local disk should also be moved behind the SourceLocator interface?
I am thinking,
std::optional<FileSpec> ResolveSourceFile( ModuleSpec, FileSpec) // or Module ?
or
FileSpec ResolveSourceFile( ModuleSpec, FileSpec) // or Module ?
Plugin structure could be
DefaultSourcelocator ( handle using existing cache files, local source files and source-maps)
I asked/suggested something similar in the other RFC, but is there any reason this cannot fit in the existing SymbolLocator plugins? In other words, is locating source files sufficiently orthogonal to finding symbol files? I would argue it’s probably not: SymbolLocatorDefault (looking at the file system) and SymbolLocatorDebuginfod (querying debuginfod) seem like a perfect fit for what you’re describing. Plus that way we don’t have to do both a ScriptedSymbolLocator and a ScriptedSourceLocator if folks want to provide a custom implementation from Python.
yes it could fit in the exiting symbollocator plugin, The only issue I have is in the name because it does not show resolving source files is part of the interface. Unless sources can be classified as a symbol.
Yeah, SymbolLocator was already an inexact name for this plugin before source got mentioned.
It can’t mean what it literally says because you already have Symbols in general and if the “SymbolLocator” really only dealt with Symbols the best it could add is the stripped symbols from the binary…
Once you agree that this had to mean debug information then the extension to source information is pretty natural.
DebugInfoLocator
would probably have been a better name, not sure why we didn’t choose that.
I converted LocateSymbolFile to a plugin and kept the name. I think it’s mostly historical, probably inspired by the DebugSymbols.framework, similar to the Symbols on macOS page on the website. If folks think it’s worth the churn to rename it, I’m happy to do that.
People do use “Having symbols” to mean “Having debug information”, so it’s not that bad. After all, if people just meant “Has linker/loader symbols” I don’t think “Having Symbols” would be particularly noteworthy…
The link to the draft PR is in the original post and likely what prompted this RFC in the first place. Regarding the PR and the comment about boilerplate, moving this into the SymbolLocatorPlugin (DebugInfoLocator) plugin will sidestep almost all of that.