From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25806 invoked by alias); 8 Jan 2007 07:44:55 -0000 Received: (qmail 25777 invoked by uid 22791); 8 Jan 2007 07:44:52 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 08 Jan 2007 07:44:48 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H3pBQ-0002ga-5p for gdb-patches@sources.redhat.com; Mon, 08 Jan 2007 10:44:45 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1H3pBF-0002gK-AV; Mon, 08 Jan 2007 10:44:29 +0300 From: Vladimir Prus Subject: Re: MI testsuite failures To: Nick Roberts , gdb-patches@sources.redhat.com Date: Mon, 08 Jan 2007 07:44:00 -0000 References: <17825.33653.885121.321357@kahikatea.snap.net.nz> User-Agent: KNode/0.10.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8Bit Message-Id: Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00220.txt.bz2 Nick Roberts wrote: > > I notice now that my last change introduced several testsuite failures: FWIW, it would be best if you run MI testsuite before *sending* a patch ;-) > > FAIL: gdb.mi/mi2-var-cmd.exp: update all vars: func and lpsimple changed > FAIL: gdb.mi/mi2-var-cmd.exp: update all vars: linteger changed after > assign > > These are because GDB notices that string contents have been changed and > just need an extra output field, which I guess is a good thing. > > > FAIL: gdb.mi/mi-var-cmd.exp: assign same value to func (update) > > This is more subtle and is caused by having two variable objects for > one variable, var1 and var2 say. Then if they have a common value 10 > say and you do: > > -var-assign var1 11 > -var-assign var2 12 > > var->updated is set to 1 for each and they are both reported as changed > with -var-update. > > However doing -var-update again gives var1 in the chagelist because the > real value is 12 but var->print_value is "11". That's because -var-assign should update var->print_value. > I think this is a bug in -var-assign; it should set the variable value > but not interfere with the variable object. Note that generally if you > have two variable objects for one value and set the value of one with > -var-assign, one will be reported as changed because var->updated is 1, > and the other because the value has changed. I think the value held > by the variable object shouldn't change until -var-update is issued, > just as is the case if the real value changes during execution. This is > a patch to do that. I don't think that if you assign a value to varobj and then -var-evaluate-expression returns something else than the value you've assigned, it would be rather confusing interface. > --- varobj.h    7 Jan 2007 23:27:50 -0000 > *************** extern int varobj_get_attributes (struct > *** 93,99 **** >   >   extern char *varobj_get_value (struct varobj *var); >   > ! extern int varobj_set_value (struct varobj *var, char *expression); >   >   extern int varobj_list (struct varobj ***rootlist); >   > --- 93,99 ---- >   >   extern char *varobj_get_value (struct varobj *var); >   > ! extern char* varobj_set_value (struct varobj *var, char *expression); >   >   extern int varobj_list (struct varobj ***rootlist); >   > Index: varobj.c > =================================================================== > RCS file: /cvs/src/src/gdb/varobj.c,v > retrieving revision 1.76 > diff -c -p -r1.76 varobj.c > *** varobj.c    5 Jan 2007 21:58:48 -0000       1.76 > --- varobj.c    7 Jan 2007 23:27:54 -0000 > *************** varobj_get_value (struct varobj *var) > *** 797,808 **** >      value of the given expression */ >   /* Note: Invokes functions that can call error() */ >   > ! int >   varobj_set_value (struct varobj *var, char *expression) >   { >     struct value *val; > !   int offset = 0; > !   int error = 0; >   >     /* The argument "expression" contains the variable's new value. >        We need to first construct a legal expression for this -- ugh! */ > --- 797,807 ---- >      value of the given expression */ >   /* Note: Invokes functions that can call error() */ >   > ! char* >   varobj_set_value (struct varobj *var, char *expression) >   { >     struct value *val; > !   char* print_value; >   >     /* The argument "expression" contains the variable's new value. >        We need to first construct a legal expression for this -- ugh! */ > *************** varobj_set_value (struct varobj *var, ch > *** 822,864 **** >         { >           /* We cannot proceed without a valid expression. */ >           xfree (exp); > !         return 0; >         } >   > -       /* All types that are editable must also be changeable.  */ > -       gdb_assert (varobj_value_is_changeable_p (var)); > - > -       /* The value of a changeable variable object must not be lazy.  */ > -       gdb_assert (!value_lazy (var->value)); You're removing a bunch of asserts again, and I see no reason why. > - > -       /* Need to coerce the input.  We want to check if the > -        value of the variable object will be different > -        after assignment, and the first thing value_assign > -        does is coerce the input. > -        For example, if we are assigning an array to a pointer variable we > -        should compare the pointer with the the array's address, not with the > -        array's content.  */ > -       value = coerce_array (value); What's the reason for removing this block? > - > -       /* The new value may be lazy.  gdb_value_assign, or > -        rather value_contents, will take care of this. > -        If fetching of the new value will fail, gdb_value_assign > -        with catch the exception.  */ >         if (!gdb_value_assign (var->value, value, &val)) >         return 0; > !       > !       /* If the value has changed, record it, so that next -var-update can > !        report this change.  If a variable had a value of '1', we've set it > !        to '333' and then set again to '1', when -var-update will report this > !        variable as changed -- because the first assignment has set the > !        'updated' flag.  There's no need to optimize that, because return value > !        of -var-update should be considered an approximation.  */ > !       var->updated = install_new_value (var, val, 0 /* Compare values. */); >         input_radix = saved_input_radix; > !       return 1; >       } >   > !   return 0; >   } >   >   /* Returns a malloc'ed list with all root variable objects */ > --- 821,839 ---- >         { >           /* We cannot proceed without a valid expression. */ >           xfree (exp); > !         return NULL; >         } >   >         if (!gdb_value_assign (var->value, value, &val)) >         return 0; > ! > !       print_value = value_get_print_value (val, var->format); >         input_radix = saved_input_radix; > ! > !       return print_value; As I say above, I'm not comfortable with -var-assign not changing the value of varobj itself. - Volodya