This is just a rough high level idea, which I got from breakpoint command. This allows user’s command to be executed before/after(or controlled by a flag) source content is requested either by source list or walking through the stack.
When doing postmodern debugging, we usually only have dump file (core dump or minidump), binary files and debug info files. If we want to lookup source content while debugging in lldb, we need to download the entire repository and checkout to correct revision, which could be super large. In chromium windows build, we embed source file info into the debug info files(PDB) . WinDbg downloads the sources on demand using the embedded source info, which includes source server, file revision, etc. That’s why chromium developers are able to do source level debugging with WinDbg. Also see Bruce’s blog
The main purpose of this command is to allow python script to be registered to achieve the ability of downloading sources from source server. It can be either used as a fallback if lldb failed to find the sources itself or callback to download sources before lldb trying to search.
I’m not sure if something like source command is the simplest approach.
The idea of registering a Python callback to realize files that aren’t where the debug info says they should be seems good. We do something slightly different to find debug information for Modules (providing a callout to a command-line tool instead of a a python callback.) But there’s precedent for the idea. We have a source manager that’s responsible for fetching source files, so you can most likely find somewhere in there to add your hook.
It would be good to do both a command-line command to register the callback, and some SB API for the same purpose that would be more friendly to programmatic uses of lldb.
“source command” seems a little generic for what is a pretty specific command. Adding this feature will also mean we now have a couple of ways of finding “lost” source files, this and the “source-map” AND the source-maps that can get embedded in debug info files. So it might be good at this point to gather these bits into one place, so you can order them, deal with what happens if libraries A-C get their sources from some server, D-G from another server and H-J from a source-map translation, etc… Maybe starting a “source fetch” subcommand and putting these ways of doing it under that will give us more flexibility as we figure out what interface works best?
Anyway, the general idea seems good.
Jim
Thank you for the feedback.