[RFA/MI testsuite] gdb/701 test (varobj)

[RFA/MI testsuite] gdb/701 test (varobj)

[Keith Seitz]

Hi,

The test below tickles a crashing bug in gdb's varobj code, as reported in 
gdb/701.

[I felt it was a lot easier to add a new test file than to try to 
integrate this into the existing tests -- too many line numbers to reorder 
if adding a line into var-cmd.c...]

Keith

ChangeLog
2002-09-13  Keith Seitz  <keiths@redhat.com>

	* gdb701.exp: New file for testing varobj target type bug.
	* gdb701.c: New file.

Patch
Index: testsuite/gdb.mi/gdb701.c
===================================================================
RCS file: testsuite/gdb.mi/gdb701.c
diff -N testsuite/gdb.mi/gdb701.c
*** testsuite/gdb.mi/gdb701.c	1 Jan 1970 00:00:00 -0000
--- testsuite/gdb.mi/gdb701.c	13 Sep 2002 23:47:55 -0000
***************
*** 0 ****
--- 1,15 ----
+ struct _foo
+ {
+   int x;
+   int y;
+   int z;
+ };
+ 
+ typedef struct _foo Foo;
+ 
+ int
+ main (int argc, char *argv[])
+ {
+   Foo *foo = 0;
+   exit (0);
+ }
Index: testsuite/gdb.mi/gdb701.exp
===================================================================
RCS file: testsuite/gdb.mi/gdb701.exp
diff -N testsuite/gdb.mi/gdb701.exp
*** testsuite/gdb.mi/gdb701.exp	1 Jan 1970 00:00:00 -0000
--- testsuite/gdb.mi/gdb701.exp	13 Sep 2002 23:47:55 -0000
***************
*** 0 ****
--- 1,67 ----
+ # Copyright 2002 Free Software Foundation, Inc.
+ 
+ # This program is free software; you can redistribute it and/or modify
+ # it under the terms of the GNU General Public License as published by
+ # the Free Software Foundation; either version 2 of the License, or
+ # (at your option) any later version.
+ # 
+ # This program is distributed in the hope that it will be useful,
+ # but WITHOUT ANY WARRANTY; without even the implied warranty of
+ # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ # GNU General Public License for more details.
+ # 
+ # You should have received a copy of the GNU General Public License
+ # along with this program; if not, write to the Free Software
+ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+ 
+ # Please email any bugs, comments, and/or additions to this file to:
+ # bug-gdb@prep.ai.mit.edu
+ 
+ #
+ # test gdb/701
+ #
+ 
+ load_lib mi-support.exp
+ set MIFLAGS "-i=mi"
+ 
+ gdb_exit
+ if [mi_gdb_start] {
+     continue
+ }
+ 
+ set testfile gdb701
+ set srcfile "$testfile.c"
+ set binfile $objdir/$subdir/$testfile
+ if {[gdb_compile $srcdir/$subdir/$srcfile $binfile executable debug] != ""} {
+   gdb_suppress_entire_file "Testcase compile failed, so all test in this file will automatically fail."
+ }
+ 
+ # When varobj reports the types of objects, it often isn't really reporting
+ # the type as GDB knows it. For example, in this testcase, we have a
+ # structure which has been typedefed. A varobj of this type would really have
+ # a type of "TYPE_CODE_TYPEDEF". It's target type is "TYPE_CODE_STRUCT". Varobj
+ # should skip over the TYPEDEF type when figuring out the varobj's children.
+ # If it doesn't, Bad Things Happen(TM).
+ 
+ # Run to main
+ mi_run_to_main
+ 
+ # Step over "foo = 0"
+ mi_next "step over \"foo = 0\""
+ 
+ mi_gdb_test "-var-create fooPtr * foo" \
+   "(&\".*\"\r\n)*\\^done,name=\"fooPtr\",numchild=\"3\",type=\"Foo \\*\"" \
+   "create fooPtr"
+ 
+ mi_gdb_test "-var-list-children fooPtr" \
+   "(&\".*\"\r\n)*\\^done,numchild=\"3\",.*" \
+   "list children of fooPtr"
+ 
+ foreach i [list x y z] {
+   mi_gdb_test "-var-list-children fooPtr.$i" \
+     "(&\".*\"\r\n)*\\^done,numchild=\"0\"" \
+     "list children of fooPtr.$i"
+ }
+ 
+ mi_gdb_exit
+ return 0

Re: [RFA/MI testsuite] gdb/701 test (varobj)

[Fernando Nasser]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

As you are at it, canyou take a look at this old patch of mine that I've 
found lost in a branch....  Something should be broken without it!

Regards,
Fernando


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

[-- Attachment #2: MI.PATCH --]
[-- Type: text/plain, Size: 1475 bytes --]

Index: mi/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/mi/ChangeLog,v
retrieving revision 1.69
diff -c -p -r1.69 ChangeLog
*** mi/ChangeLog	11 Sep 2002 21:49:04 -0000	1.69
--- mi/ChangeLog	14 Sep 2002 00:23:46 -0000
***************
*** 1,3 ****
--- 1,7 ----
+ 2001-01-27  Fernando Nasser  <fnasser@redhat.com>
+ 
+ 	* mi-cmd-var.c (varobj_update_one): Get a new handle if type changed.
+ 
  2002-09-11  Keith Seitz  <keiths@redhat.com>
  
  	* mi-main.c (mi_cmd_data_list_register_names): Use cleanups
Index: mi/mi-cmd-var.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-var.c,v
retrieving revision 1.12
diff -c -p -r1.12 mi-cmd-var.c
*** mi/mi-cmd-var.c	30 Jul 2002 13:45:15 -0000	1.12
--- mi/mi-cmd-var.c	14 Sep 2002 00:23:46 -0000
*************** varobj_update_one (struct varobj *var)
*** 458,463 ****
--- 458,464 ----
    struct varobj **changelist;
    struct varobj **cc;
    int nc;
+   char *varname = varobj_get_objname(var);
  
    nc = varobj_update (&var, &changelist);
  
*************** varobj_update_one (struct varobj *var)
*** 475,480 ****
--- 476,482 ----
      }
    else if (nc == -2)
      {
+       var = varobj_get_handle (varname);
        ui_out_field_string (uiout, "name", varobj_get_objname (var));
        ui_out_field_string (uiout, "in_scope", "true");
        ui_out_field_string (uiout, "new_type", varobj_get_type(var));

Re: [RFA/MI testsuite] gdb/701 test (varobj)

[Keith Seitz]

On Fri, 13 Sep 2002, Fernando Nasser wrote:

> As you are at it, canyou take a look at this old patch of mine that I've 
> found lost in a branch....  Something should be broken without it!

I can take a look at it. It seems to me that this looks plausible. I'll 
see if I can add some more test which check the type-changing stuff. As I 
recall, we've historically had some problems with this code. Having a 
testcase should clear things up.

Keith

Re: [RFA/MI testsuite] gdb/701 test (varobj)

[Keith Seitz]

On Fri, 13 Sep 2002, Fernando Nasser wrote:

> As you are at it, canyou take a look at this old patch of mine that I've 
> found lost in a branch....  Something should be broken without it!

Ok, I've got a testcase for it... I'll be submitting it shortly.

I think your patch is now obsolete. At one time this was necessary
because when we call varobj_update, we've already gotten a pointer to our 
varobj (via varobj_get_handle). When varobj_update is called and the type 
changes, the original varobj is deleted, and a new one is created with the 
same name. I changed the API for varobj_update so that this new handle is 
propagated upward.

Thus, when varobj_update returns, the handle is still valid (if 
different). This change was committed by me on 2001-08-17.

Keith

Re: [RFA/MI testsuite] gdb/701 test (varobj)

[Fernando Nasser]

Thanks for checking this out Keith.

Regards,
Fernando

Keith Seitz wrote:
> On Fri, 13 Sep 2002, Fernando Nasser wrote:
> 
> 
>>As you are at it, canyou take a look at this old patch of mine that I've 
>>found lost in a branch....  Something should be broken without it!
> 
> 
> Ok, I've got a testcase for it... I'll be submitting it shortly.
> 
> I think your patch is now obsolete. At one time this was necessary
> because when we call varobj_update, we've already gotten a pointer to our 
> varobj (via varobj_get_handle). When varobj_update is called and the type 
> changes, the original varobj is deleted, and a new one is created with the 
> same name. I changed the API for varobj_update so that this new handle is 
> propagated upward.
> 
> Thus, when varobj_update returns, the handle is still valid (if 
> different). This change was committed by me on 2001-08-17.
> 
> Keith
> 


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA/MI testsuite] gdb/701 test (varobj)

[Andrew Cagney]

> Hi,
> 
> The test below tickles a crashing bug in gdb's varobj code, as reported in 
> gdb/701.
> 
> [I felt it was a lot easier to add a new test file than to try to 
> integrate this into the existing tests -- too many line numbers to reorder 
> if adding a line into var-cmd.c...]

Ok. Andrew


> ChangeLog
> 2002-09-13  Keith Seitz  <keiths@redhat.com>
> 
> 	* gdb701.exp: New file for testing varobj target type bug.
> 	* gdb701.c: New file.
> 
> Patch
> Index: testsuite/gdb.mi/gdb701.c
> ===================================================================
> RCS file: testsuite/gdb.mi/gdb701.c
> diff -N testsuite/gdb.mi/gdb701.c
> *** testsuite/gdb.mi/gdb701.c	1 Jan 1970 00:00:00 -0000
> --- testsuite/gdb.mi/gdb701.c	13 Sep 2002 23:47:55 -0000
> ***************
> *** 0 ****
> --- 1,15 ----
> + struct _foo
> + {
> +   int x;
> +   int y;
> +   int z;
> + };
> + 
> + typedef struct _foo Foo;
> + 
> + int
> + main (int argc, char *argv[])
> + {
> +   Foo *foo = 0;
> +   exit (0);
> + }
> Index: testsuite/gdb.mi/gdb701.exp
> ===================================================================
> RCS file: testsuite/gdb.mi/gdb701.exp
> diff -N testsuite/gdb.mi/gdb701.exp
> *** testsuite/gdb.mi/gdb701.exp	1 Jan 1970 00:00:00 -0000
> --- testsuite/gdb.mi/gdb701.exp	13 Sep 2002 23:47:55 -0000
> ***************
> *** 0 ****
> --- 1,67 ----
> + # Copyright 2002 Free Software Foundation, Inc.
> + 
> + # This program is free software; you can redistribute it and/or modify
> + # it under the terms of the GNU General Public License as published by
> + # the Free Software Foundation; either version 2 of the License, or
> + # (at your option) any later version.
> + # 
> + # This program is distributed in the hope that it will be useful,
> + # but WITHOUT ANY WARRANTY; without even the implied warranty of
> + # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + # GNU General Public License for more details.
> + # 
> + # You should have received a copy of the GNU General Public License
> + # along with this program; if not, write to the Free Software
> + # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
> + 
> + # Please email any bugs, comments, and/or additions to this file to:
> + # bug-gdb@prep.ai.mit.edu
> + 
> + #
> + # test gdb/701
> + #
> + 
> + load_lib mi-support.exp
> + set MIFLAGS "-i=mi"
> + 
> + gdb_exit
> + if [mi_gdb_start] {
> +     continue
> + }
> + 
> + set testfile gdb701
> + set srcfile "$testfile.c"
> + set binfile $objdir/$subdir/$testfile
> + if {[gdb_compile $srcdir/$subdir/$srcfile $binfile executable debug] != ""} {
> +   gdb_suppress_entire_file "Testcase compile failed, so all test in this file will automatically fail."
> + }
> + 
> + # When varobj reports the types of objects, it often isn't really reporting
> + # the type as GDB knows it. For example, in this testcase, we have a
> + # structure which has been typedefed. A varobj of this type would really have
> + # a type of "TYPE_CODE_TYPEDEF". It's target type is "TYPE_CODE_STRUCT". Varobj
> + # should skip over the TYPEDEF type when figuring out the varobj's children.
> + # If it doesn't, Bad Things Happen(TM).
> + 
> + # Run to main
> + mi_run_to_main
> + 
> + # Step over "foo = 0"
> + mi_next "step over \"foo = 0\""
> + 
> + mi_gdb_test "-var-create fooPtr * foo" \
> +   "(&\".*\"\r\n)*\\^done,name=\"fooPtr\",numchild=\"3\",type=\"Foo \\*\"" \
> +   "create fooPtr"
> + 
> + mi_gdb_test "-var-list-children fooPtr" \
> +   "(&\".*\"\r\n)*\\^done,numchild=\"3\",.*" \
> +   "list children of fooPtr"
> + 
> + foreach i [list x y z] {
> +   mi_gdb_test "-var-list-children fooPtr.$i" \
> +     "(&\".*\"\r\n)*\\^done,numchild=\"0\"" \
> +     "list children of fooPtr.$i"
> + }
> + 
> + mi_gdb_exit
> + return 0
> 
> 

Re: [RFA/MI testsuite] gdb/701 test (varobj)

[Keith Seitz]

On Fri, 13 Sep 2002, Andrew Cagney wrote:

> Ok. Andrew

Committed. Thanks for the quick look. Patch to fix this coming.

Keith