From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12966 invoked by alias); 9 Sep 2010 19:55:06 -0000 Received: (qmail 12953 invoked by uid 22791); 9 Sep 2010 19:55:03 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from imr4.ericy.com (HELO imr4.ericy.com) (198.24.6.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 09 Sep 2010 19:54:55 +0000 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o89K4G3m011494 for ; Thu, 9 Sep 2010 15:04:18 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.10]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 9 Sep 2010 15:54:47 -0400 From: Marc Khouzam To: "'gdb-patches@sourceware.org'" Date: Thu, 09 Sep 2010 20:01:00 -0000 Subject: [RFC][patch] Tweak output of -var-info-path-expression Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes 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: 2010-09/txt/msg00207.txt.bz2 Hi, Bug 11912 (http://sourceware.org/bugzilla/show_bug.cgi?id=3D11912) is causing a syntax error when casting to a class in certain cases. (see small session below for example)=20=20 In cases as 'print (*(myClass*) this)' the parser is confusing the class name 'myClass' with its=20 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=20 -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=20 admit that the implications of this change are not clear to me. Thanks for any feedback Marc 2010-09-08 Marc Khouzam * 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D xstrprintf ("(%s(%s%s) %s)",=20 + construct. +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 + 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 =3D xstrprintf ("(%s(class %s%s) %s)", ptr,=20 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=20 Breakpoint 1, foo::test (this=3D0xbfffbbf3) at base.cc:5 5 void test() { return; } (gdb) interpreter-exec mi "-var-create - * this" ^done,name=3D"var1",numchild=3D"1",value=3D"0xbfffbbf3",type=3D"foo * const= ",thread-id=3D"1",has_more=3D"0" (gdb) interpreter-exec mi "-var-list-children var1" ^done,numchild=3D"1",children=3D[child=3D{name=3D"var1.bar",exp=3D"bar",num= child=3D"0",type=3D"bar",thread-id=3D"1"}],has_more=3D"0" (gdb) interpreter-exec mi "-var-info-path-expression var1.bar" ^done,path_expr=3D"(*(bar*) this)" (gdb) interpreter-exec mi '-data-evaluate-expression "(*(bar*) this)"' ^error,msg=3D"A syntax error in expression, near `) this)'." (gdb) interpreter-exec mi '-data-evaluate-expression "(*(class bar*) this)"' ^done,value=3D"{}"