[Lldb-commits] [lldb] [lldb] Add support for updating string during debug process (PR #67782)

[Pavel Kosov via lldb-commits]

kpdev wrote:

Hello, @jimingham , first of all - sorry for the long delay in reply.

I carefully read through all your messages once again and found, that I totally misunderstood some places, i.e. "Why isn't it enough to have the ValueObjectSynthetic's SetValueFromCString do this" - I think it should be enough, I'll fix it.

> 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

I agree with this, but I think there is not so much aggregates for which it makes sense to change their length as for strings (at least in libcxx) - I mean it is natural to update whole string to completely different value, but it is not natural to do so for e.g. vector. In case of strings, one might want to set string longer, than the one he has now for the debug purposes, so this will indeed invalidate code, that relies on the pointers that was obtained through `.data` or `.c_str` methods, but it is the programmer responsibility to care about this. This it the same behaviour as if you change your string in the program - you should update your pointers.

> However, I think it's confusing here to start with the model that ValueObjects with SCPs have "underlying strings".  

Sorry, I think that I didn't express my thoughts carefully, by the underlying string I didn't mean, that we have some string in the SCP or ValueObjects, I meant the strings in the code that is under debug. 

> By the way, as a side note, watching the part of your example where you change the raw string guts, it looks like we don't update summaries of a ValueObject if one of its children gets changed.  Be good to file bug on that one so we don't forget.

I'm not sure that this bug might be reproduced without the string example, I don't know which type have the summary which represent all its children. Is it ok, to file a bug with current strings example or how to do it better?

> In the case of std::strings, which seems to be your primary motivator here, I think considering the string value to be the summary makes the most sense  

And in the end, may I kindly ask you to clarify your position about these changes please? Do you suggest to return to the `SetSummaryFromCString` API?


https://github.com/llvm/llvm-project/pull/67782