kpdev wrote:

> Getting the SyntheticFrontEnd to try updating the synthetic value is a good 
> addition. But I'm not sure that ValueObject should be the one that should 
> provide access directly to the FrontEnd? Why isn't it enough to have the 
> ValueObjectSynthetic's SetValueFromCString do this? If you have decided to 
> pull the Non-synthetic value (and so are accessing the ValueObjectVariable 
> directly, would you expect to have the synthetic value do an update? When 
> would something that is a ValueObject but not a ValueObjectSynthetic really 
> want to update the value using the SyntheticFrontEnd?


@jimingham In my understanding, the situation is looks like this:

When somebody wants to update a value from lldb API, then SBValue's 
`SetValueFromCString` method should be used,  which in turn calls 
ValueObjectVariable / ValueObjectRegister / etc.'s method `SetValueFromCString` 
- all of them currently working only with `Scalar`s, which represent addresses 
for structured values (e.g., std::string in our case) in the process that we 
debug.

I do not see a common way to update aggregate types in ValueObject* since it 
can represent any type of data, but if we have defined synthetic children for 
the concrete structure we want to update, then we can explicitly define there 
how to update it.

So, in case of std::string we can't simply copy a new c-string value to a 
location of an old c-string value; we have to destroy the old string (free 
memory) and create a new one. It can be done in expression evaluation for 
example.

I might misunderstand something in this problem, if so - please point me the 
right way. 

https://github.com/llvm/llvm-project/pull/67309
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to