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