From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23225 invoked by alias); 4 May 2006 05:30:26 -0000 Received: (qmail 23217 invoked by uid 22791); 4 May 2006 05:30:25 -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; Thu, 04 May 2006 05:30:24 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FbWPs-0005Da-ON for gdb-patches@sources.redhat.com; Thu, 04 May 2006 09:30:21 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FbWPl-0005Bs-Nr; Thu, 04 May 2006 09:30:13 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: Variable objects: references formatting Date: Thu, 04 May 2006 05:30:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb-patches@sources.redhat.com References: <17497.14121.225320.477428@farnswood.snap.net.nz> In-Reply-To: <17497.14121.225320.477428@farnswood.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605040930.11191.ghost@cs.msu.su> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00030.txt.bz2 On Thursday 04 May 2006 03:05, Nick Roberts wrote: > There are som many things about this patch that I don't understand: > > Index: varobj.c > > =================================================================== > > RCS file: /cvs/src/src/gdb/varobj.c,v > > retrieving revision 1.58 > > Version 1.59 has been in the repository for over a month, so how come this > patch is against 1.58? I've at least 2 other changes to that file, and corresponding patches were neither applied nor rejected, AFAICT. I'd rather not update the file yet. > > diff -u -r1.58 varobj.c > > @@ -2055,8 +2219,14 @@ > > I'm not used to unified diffs, but as insertion appears to be done at the > same place why is it not something like: > > @@ -2055,8 +2055,14 @@ I'm sorry, I don't understand that question. This hunk was cut from a larger diff, maybe that explains something? > > { > > /* BOGUS: if val_print sees a struct/class, it will print out its > > children instead of "{...}" */ > > + struct type* type = get_type (var); > > + /* Strip top-level references. */ > > + while (TYPE_CODE (type) == TYPE_CODE_REF) > > + { > > + type = TYPE_TARGET_TYPE (type); > > + } > > > > - switch (TYPE_CODE (get_type (var))) > > + switch (TYPE_CODE (type)) > > { > > case TYPE_CODE_STRUCT: > > case TYPE_CODE_UNION: > > Most importantly, however, the preamble is about -data-evaluate-expression > but AFAICS this doesn't call c_value_of_variable. Sure it does. KDevelop uses -data-evaluate-expression to fetch values, and with this patch the value of "reference to structure" is rendered as "...", just like I'd want. > > I have tested the output of -data-evaluate-expression on pointers to > typedeffed structures and found that with the latter I get a {}-enclosed > list of members with gcc 3.2 and {...} with gcc 4.1. More generally, I > have found that gcc 4.1 treats typedefs differently, which leads to errors > with variable objects. How *pointers* to typedeffed structures are relevant to this patch? Now, maybe we need to call 'check_typedef' in one more place -- after stripping reference, to make sure typedefs to structures are also rendered as "...". Is that what you're saying? And what errors do you see with gcc 4.1? - Volodya