================
@@ -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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
