[lldb-dev] Execution contexts in the OptionValue subsystem?

[Sean Callanan via lldb-dev]

I was evaluating whether to provide one in a target setting, and I 
decidednot to.

Then I was looking to see why anyone wouild, and I couldn't find anyone 
actually using it.

It's a little painful to see it passed around everywhere rather 
thanstored by Process or Target, the two thingsthat care...but it's not 
getting in the way of my work.

Sean

On 7/21/17 4:51 PM, Jim Ingham wrote:
> Was this just curiosity, or was this getting in your way somehow?
>
> Jim
>
>> On Jul 21, 2017, at 4:50 PM, Jim Ingham via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>>
>>> On Jul 21, 2017, at 4:41 PM, Sean Callanan via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>>
>>> There's a function in OptionValueProperties (http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup line 234):
>>>
>>> const Property *OptionValueProperties::GetPropertyAtIndex(
>>>     const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const {
>>>   return ProtectedGetPropertyAtIndex(idx);
>>> }
>>>
>>> Its callers  go to some trouble to collect and pass around the ExecutionContext (e.g., GetSubValue passes it around everywhere, GetPropertyAtrIndexAs* has to keep it everywhere, the Dump mechanism passes around ExecutionContexts, etc.)
>>>
>>> Aside from calling this function with completely ignores the ExecutionContext, I don't see the execution contexts getting used anywhere.  Is this a remnant from old code?
>> For instance (from Process.cpp):
>>
>> class ProcessOptionValueProperties : public OptionValueProperties {
>> public:
>>   ProcessOptionValueProperties(const ConstString &name)
>>       : OptionValueProperties(name) {}
>>
>>   // This constructor is used when creating ProcessOptionValueProperties when it
>>   // is part of a new lldb_private::Process instance. It will copy all current
>>   // global property values as needed
>>   ProcessOptionValueProperties(ProcessProperties *global_properties)
>>       : OptionValueProperties(*global_properties->GetValueProperties()) {}
>>
>>   const Property *GetPropertyAtIndex(const ExecutionContext *exe_ctx,
>>                                      bool will_modify,
>>                                      uint32_t idx) const override {
>>     // When getting the value for a key from the process options, we will always
>>     // try and grab the setting from the current process if there is one. Else
>>     // we just
>>     // use the one from this instance.
>>     if (exe_ctx) {
>>       Process *process = exe_ctx->GetProcessPtr();
>>       if (process) {
>>         ProcessOptionValueProperties *instance_properties =
>>             static_cast<ProcessOptionValueProperties *>(
>>                 process->GetValueProperties().get());
>>         if (this != instance_properties)
>>           return instance_properties->ProtectedGetPropertyAtIndex(idx);
>>       }
>>     }
>>     return ProtectedGetPropertyAtIndex(idx);
>>   }
>> };
>>
>> That's what tells you whether to use the global process property, or this process specific one.  Ditto for Thread properties.
>>
>> Jim
>>
>>
>>> Sean
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170721/93a8ca88/attachment-0001.html>