[Lldb-commits] [lldb] [lldb] Expand background symbol lookup (PR #80890)

[Jason Molenda via lldb-commits]

================
@@ -5,10 +5,11 @@ let Definition = "modulelist" in {
     Global,
     DefaultTrue,
     Desc<"Control the use of external tools and repositories to locate symbol files. Directories listed in target.debug-file-search-paths and directory of the executable are always checked first for separate debug info files. Then depending on this setting: On macOS, Spotlight would be also used to locate a matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory /usr/libdata/debug would be also searched. On platforms other than NetBSD directory /usr/lib/debug would be also searched. If all other methods fail there may be symbol-locator plugins that, if configured properly, will also attempt to acquire symbols. The debuginfod plugin defaults to the DEGUFINFOD_URLS environment variable which is configurable through the 'plugin.symbol-locator.debuginfod.server_urls' setting.">;
-  def EnableBackgroundLookup: Property<"enable-background-lookup", "Boolean">,
+  def LazySymbolLookup: Property<"lazy-lookup", "Enum">,
----------------
jasonmolenda wrote:

I keep coming back to synonyms for "on demand" but not clear why they are different, like "as-needed-symbol-lookup".  Or "backtrace-driven-symbol-lookup".  

I don't know if there's any really clear name that could help a first-time user to distinguish between the different mechanisms.  We have the existing `symbols.load-on-demand` which is really avoiding loading the DWARF for any binaries until criteria are met (if I'm reading the docs/use/ondemand.rst correctly).  In this case, lldb *has* the DWARF for the binaries locally, it's just not reading it until the debug info is needed (with a few caveats like "breakpoints by name on inlined functions won't work").

This mechanism is instead "Download the DWARF (dSYM) and executable (if possible) from an external server, and load it immediately in to lldb".  For instance, you connect to a process on a remote system and none of the binaries running on the remote system, e.g. libsystem_c.dylib, exist on the host computer.  lldb can use this mechanism to download the correct libsystem_c.dylib and libsystem_c.dylib.dSYM to the host computer and load them in to lldb.  Instead of doing that for *all* binaries on connect, this allows us to avoid hitting the external servers until specific binaries are needed.

I might try to work 'symbol-download' into the setting name, that is a real difference between the two.

https://github.com/llvm/llvm-project/pull/80890