jimingham wrote: First off, note that the case of std::strings is slightly orthogonal to what you are doing here, because the thing that provides the "semantic" value for a std::string is the std::string Summary Formatter. std::string doesn't actually have a synthetic front end provider. So you would have to do parallel work on making "mutating summary providers" if you want to support the use case of changing std::string's. You'd probably want to add a "SetValueFromSummaryString" to tell the summary provider to decode the incoming string value and figure out how to splat it onto the current object.
Secondly, lldb only supports changing scalars because it's hard to give meaning to "changing an aggregate object". You have to change it in situ - which really means changing the values of its contents, i.e. its children - or you will end up invalidating code that relies on the location of the aggregate. You have to do some kind of "copy" or "move". We don't try to give meaning to "change a whole structure's contents", because it's more natural to go to the children one by one and set them to the new values. Synthetic child providers are all about making an object appear like an aggregate. So again, I'm not sure what it would mean to change the whole synthetic value. The natural operation here would be "change the value of one of the children the synthetic provider produces." This will often still need the cooperation of the Synthetic value's FrontEndProvider to know how to do that. For instance, the synthetic children for a std::vector<int> could just point to the int in memory, and they can directly write to that memory. In other cases the children don't exist in the program memory, but are either made up in lldb's address space, or allocated in the target. In those cases you would have to get the Synthetic FrontEnd involved, to figure out what it would mean to change the underlying value for that child. But in any case, it seems to me the request goes from the synthetic child up to the parent, so I would imagine that SetValueFromCString on a synthetic child would ask the ValueObjectSynthetic that is it's parent to do: "SetValueForChildFromCString". Jim > On Sep 26, 2023, at 11:44 PM, Pavel Kosov ***@***.***> 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 <https://github.com/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 Scalars, 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. > > — > Reply to this email directly, view it on GitHub > <https://github.com/llvm/llvm-project/pull/67309#issuecomment-1736795805>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADUPVWZXZWZ7AYXLIM6CM5DX4PDLNANCNFSM6AAAAAA5F4RBKA>. > You are receiving this because you were mentioned. > 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
