[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

Tue Apr 9 13:08:05 PDT 2019

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