From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6115 invoked by alias); 4 May 2006 06:21:50 -0000 Received: (qmail 6107 invoked by uid 22791); 4 May 2006 06:21:49 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 May 2006 06:21:46 +0000 Received: from farnswood.snap.net.nz (p202-124-114-135.snap.net.nz [202.124.114.135]) by viper.snap.net.nz (Postfix) with ESMTP id 38440756251; Thu, 4 May 2006 18:21:44 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 500) id 66FA0627ED; Thu, 4 May 2006 07:22:01 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17497.40328.776132.200023@farnswood.snap.net.nz> Date: Thu, 04 May 2006 06:21:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: Variable objects: references formatting In-Reply-To: <200605040930.11191.ghost@cs.msu.su> References: <17497.14121.225320.477428@farnswood.snap.net.nz> <200605040930.11191.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 22.0.50.43 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/msg00034.txt.bz2 > > 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. > > > 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? Similarly, in general, the patch presumably won't apply properly. > > 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? > > 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. -- Nick http://www.inet.net.nz/~nickrob