Re: RFC: MI - Detecting change of string contents with variable objects

[Daniel Jacobowitz <drow@false.org>]

On Fri, Jan 05, 2007 at 09:34:53AM +1300, Nick Roberts wrote:
>  > Otherwise the patch seems fine, if it tests OK, but I'm still a little
>  > nervous about it.  For example, you'll call val_print on a struct
>  > or array to see if it's changed.  Depending on things like "set print
>  > elements", that might not print out the whole string.  This is
>  > probably a behavior change.  Is it a harmless one?  If it is, then
>  > should we be sharing the code with c_value_of_variable that avoids
>  > printing structs, unions, and arrays, and never mark them as changed
>  > unless their types change?
> 
> The function val_print is already used for -var-evaluate-expression.

Not in the case I was talking about.  -var-evaluate-expression calls
varobj_get_value, which calls c_value_of_variable, and will return
"{...}" for a struct.  Won't it?

> AFAICS "set print elements" has no effect on variable objects,
> perhaps because val_print is only called on the leaves but I can see
> that using it might expose MI to the vagaries of CLI.  Currently,
> however, string changes don't get reported at all, without the user
> changing configuration values.

"set print elements" will affect the output of character pointers, but
that's not really what I'm worried about - you're now going to print
out most of an array or struct when comparing print_value.

1. Can always set print_value to what c_value_of_variable would return?

2. Currently I believe we will mark an array varobj as updated in
-var-update if any of its children change.  I'm not sure if we'll do
that any more after your patch, e.g. if something beyond the limit of
"set print elements" changes.  So, do you think any front end relies on
the parent being marked updated if any of its children are?  Vlad,
any opinion?

-- 
Daniel Jacobowitz
CodeSourcery