From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20121 invoked by alias); 4 May 2006 07:00:33 -0000 Received: (qmail 20112 invoked by uid 22791); 4 May 2006 07:00:32 -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 07:00:30 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FbXp0-0004x7-4p for gdb-patches@sources.redhat.com; Thu, 04 May 2006 11:00:27 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FbXop-0004uB-FB; Thu, 04 May 2006 11:00:12 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: Variable objects: references formatting Date: Thu, 04 May 2006 07:00:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb-patches@sources.redhat.com References: <17497.14121.225320.477428@farnswood.snap.net.nz> <200605040930.11191.ghost@cs.msu.su> <17497.40328.776132.200023@farnswood.snap.net.nz> In-Reply-To: <17497.40328.776132.200023@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: <200605041100.09748.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/msg00035.txt.bz2 On Thursday 04 May 2006 10:22, Nick Roberts wrote: > > > 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. > > And I would think people on this mailing list would rather not work out > the patch relative to current CVS in order to apply. I know it worked in > this case (after a shift) but it wouldn't in general. Well, if you say patches against the previous revision of a file cause problems, I'll try to send patches against most current version in future. > > > 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 could say "Oh know it doesn't!" but, since this is not a pantomime, could > you please give me a simple example of where it does call > c_value_of_variable. My loose reasoning is that the variable in > "c_value_of_variable" refers to variable object and > -data-evaluate-expression doesn't use one. What argument do you give it? It looks like small typo caused a lot of confusion. I meant -var-evaluate-expression, not -data-evaluate-expression. Sorry for confusing this. > > > 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? > > No, I just didn't appreciate the difference between pointers and references > in GDB. The discrepancy I "found" was due to me mistyping. However I do > see a problem with gcc 4.1 and variable objects where GDB keeps telling me: > > Child of parent whose type does not allow children > > when it didn't when my program was compiled with gcc 3.2. Again, maybe you can provide specific case where this error is produced? If it affect real-world cases we'd better fix it soon. - Volodya