[Lldb-commits] [lldb] [lldb] Add `SBModule.SetLocateDwoCallback` (PR #69517)

[via lldb-commits]

jimingham wrote:

Given that the Modules that we create are a shared resource for all Debuggers, it would be strange to have two debuggers with different paths.  Would you want to tell debugger A whose callback didn't locate the DWO that it has no debug info, but the one whose callback did locate it that it did?  That would be odd, I'm pretty sure confusing (and we have no way to do that at present).

But note, this isn't the only version of this complication from having the shared module cache.  For instance, if you create a target A that debugs executable E but hasn't set the "target.debug-file-search-paths" to point to where the debug info is, and ask E for it's debug info, it won't have any.  Then you make target B that also debugs E but has the search paths set so we find the debug info for E.  Next time A looks at this module, it will suddenly have debug info for E, which is nice... but also spooky.

We get a lot of benefit from the shared module cache however, particularly in long running applications like Xcode, and in targets with lots of system shared modules, but it does introduce these odd corner cases.

Jim


> On Oct 23, 2023, at 3:58 PM, Alex Langford ***@***.***> wrote:
> 
> 
> In that case, maybe it doesn't make sense for every Debugger to have its own callback and SymbolFile should own it? Can't say I'm a fan of having this effectively be a global variable since I've seen it be an issue in other situations (e.g. Logging).
> 
> —
> Reply to this email directly, view it on GitHub <https://github.com/llvm/llvm-project/pull/69517#issuecomment-1776153786>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVWYLKULO56FMLNGD7JDYA3ZAVAVCNFSM6AAAAAA6GECPBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWGE2TGNZYGY>.
> You are receiving this because you are on a team that was mentioned.
> 



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