[RFC][patch] Tweak output of -var-info-path-expression

[RFC][patch] Tweak output of -var-info-path-expression

[Marc Khouzam]

Hi,

Bug 11912 (http://sourceware.org/bugzilla/show_bug.cgi?id=11912)
is causing a syntax error when casting to a class in
certain cases. (see small session below for example)  

In cases as 'print (*(myClass*) this)'
the parser is confusing the class name 'myClass' with its 
constructor name (if it is defined) and complains that the
cast is bad.

In the bugzilla, the work-around is to use the 'class' keyword
'print (*(class myClass*) this)'
to tell the parser  we want the class and not the constructor.
That works.

The problem is that the output of -var-info-path-expression
does not use that workaround and therefore can give an expression
that causes a syntax error.

I'm suggesting to add the workaround to the output of 
-var-info-path-expression when it casts.

It would be nicer to fix the parser problem but that
seems much more complicated (at least for me).

I've attached a patch in hopes of comments but I have to 
admit that the implications of this change are not clear to me.

Thanks for any feedback

Marc

2010-09-08  Marc Khouzam  <marc.khouzam@ericsson.com>

	* varobj.c (cplus_describe_child): Add `class'
	keyword to avoid confusion with constructor name.

### Eclipse Workspace Patch 1.0
#P src
Index: gdb/varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.160
diff -u -r1.160 varobj.c
--- gdb/varobj.c        19 Aug 2010 07:34:27 -0000      1.160
+++ gdb/varobj.c        9 Sep 2010 16:07:36 -0000
@@ -3314,8 +3314,14 @@
                 will create an lvalue, for all appearences, so we don't
                 need to use more fancy:
                         *(Base1*)(&d)
-                construct.  */
-             *cfull_expression = xstrprintf ("(%s(%s%s) %s)", 
+                construct.
+                
+                When we are in the scope of the base class or of one
+                of its children, the type field name will be interpreted
+                as a constructor, if it exists.  Therefore, we must
+                indicate that the name is a class name by using the
+                'class' keyword.  I think 'struct' or '::' would also work. */
+             *cfull_expression = xstrprintf ("(%s(class %s%s) %s)",
                                              ptr, 
                                              TYPE_FIELD_NAME (type, index),
                                              ptr,


Session showing problem:

> gdb.7.3 a.out
GNU gdb (GDB) 7.2.50.20100831-cvs
(gdb) l 1
1       class bar {};
2       class foo: bar {
3         public:
4           foo() {}  // Comment this line to make things work
5           void test() { return; }
6       //    foo *g;
7       };
8
9       int main(void)
10      {
11          foo f;
12          f.test();
13          return 0;
14      }
(gdb)  b 5
Breakpoint 1 at 0x8048457: file base.cc, line 5.
(gdb) r
Starting program: /local/lmckhou/testing/a.out 
Breakpoint 1, foo::test (this=0xbfffbbf3) at base.cc:5
5           void test() { return; }
(gdb) interpreter-exec mi "-var-create - * this"
^done,name="var1",numchild="1",value="0xbfffbbf3",type="foo * const",thread-id="1",has_more="0"

(gdb) interpreter-exec mi "-var-list-children var1"
^done,numchild="1",children=[child={name="var1.bar",exp="bar",numchild="0",type="bar",thread-id="1"}],has_more="0"

(gdb) interpreter-exec mi "-var-info-path-expression var1.bar"
^done,path_expr="(*(bar*) this)"

(gdb) interpreter-exec mi '-data-evaluate-expression "(*(bar*) this)"'
^error,msg="A syntax error in expression, near `) this)'."

(gdb) interpreter-exec mi '-data-evaluate-expression "(*(class bar*) this)"'
^done,value="{<No data fields>}"

Re: [RFC][patch] Tweak output of -var-info-path-expression

[Tom Tromey]

>>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:

Marc> Bug 11912 (http://sourceware.org/bugzilla/show_bug.cgi?id=11912)
Marc> is causing a syntax error when casting to a class in
Marc> certain cases. (see small session below for example)  

Marc> I'm suggesting to add the workaround to the output of 
Marc> -var-info-path-expression when it casts.

Marc> It would be nicer to fix the parser problem but that
Marc> seems much more complicated (at least for me).

I hate to work around other bugs, but in this case it seems practical.

Marc> I've attached a patch in hopes of comments but I have to 
Marc> admit that the implications of this change are not clear to me.

Marc> Thanks for any feedback

I think a regression test in the test suite would be valuable.

Marc> 2010-09-08  Marc Khouzam  <marc.khouzam@ericsson.com>
Marc> 	* varobj.c (cplus_describe_child): Add `class'
Marc> 	keyword to avoid confusion with constructor name.

I think the patch itself is ok, but I would like to wait a little while
to see if other maintainers, particularly Volodya, have any objections.

Tom