jingham added a comment. In D60468#1460212 <https://reviews.llvm.org/D60468#1460212>, @friss wrote:
> In D60468#1460065 <https://reviews.llvm.org/D60468#1460065>, @labath wrote: > > > No opinion on the patch, but what is the reason for having settings that > > are shared between multiple Debugger instances? My expectation was that the > > debugger objects are completely independent, and I would be surprised if > > the value of some setting changed from under me because of something that > > happened in another debug session. > > > As Jim said, there are parts of the debugger that simply do not have access > to a debugger by design. I'm honestly not sure this is the correct design in > hindsight. I tried to make the global state per-debugger, but I stopped when > I needed to change the Plugin registration to take a debugger (because > SymbolVendor plugins would need a debugger to access search paths for > example). This approach also has other challenges and breaks command > completion in non-trivial ways. > > Note that once a target is created, there is no cross-debugger contamination > anymore except if you force things by passing '-g' to 'settings set'. But it > is super weird (or rather wrong) that simple 'settings set' on one debugger > have an impact on other debuggers. Yeah, there are some settings (like target.default-arch, target.trap-handler-names, target.process.stop-on-exec and a few others) that are marked global in the PropertyDefinition, which means they always refer directly to the global (outside all debuggers) OptionValue. I can't remember why that was done. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60468/new/ https://reviews.llvm.org/D60468 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
