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

2023-10-20 Thread Tom Yang via lldb-commits
https://github.com/zhyty edited https://github.com/llvm/llvm-project/pull/69517 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

2023-10-20 Thread Tom Yang via lldb-commits
zhyty wrote: > Because SymbolFile is holding onto the function pointer as a static member, > this is a global setting that you can't apply to only just one `SBDebugger` > object. It's an all-or-nothing thing. Maybe that's what you want, but LLDB > already has architectural issues with certain

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

2023-10-23 Thread via lldb-commits
jimingham wrote: SymbolFiles can be owned by more than one debugger at a time. That's actually a very common mode for GUI's that can host more than one debugging session at a time. You can iterate over the list of debuggers from anywhere, and query the value of this property, but if two Debu

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

2023-10-23 Thread Alex Langford via lldb-commits
bulbazord 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). https://github.com/llvm/l

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

2023-10-23 Thread 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 loca