From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13937 invoked by alias); 15 Nov 2006 17:52:07 -0000 Received: (qmail 13928 invoked by uid 22791); 15 Nov 2006 17:52:06 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 15 Nov 2006 17:51:59 +0000 Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id kAFHovrX021429; Wed, 15 Nov 2006 09:50:57 -0800 (PST) Received: from [17.201.22.244] (unknown [17.201.22.244]) by relay7.apple.com (Apple SCV relay) with ESMTP id 56189F; Wed, 15 Nov 2006 09:50:57 -0800 (PST) Cc: gdb@sources.redhat.com Message-Id: From: Jim Ingham To: Vladimir Prus In-Reply-To: <200611152027.44035.vladimir@codesourcery.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Smtp-Server: relay.apple.com Mime-Version: 1.0 (Apple Message framework v854) Subject: Re: MI and anonymous unions Content-Transfer-Encoding: 7bit Date: Wed, 15 Nov 2006 17:52:00 -0000 References: <200611151238.16778.vladimir@codesourcery.com> <0F999BE0-8618-44C4-A924-EE55588784EC@apple.com> <200611152027.44035.vladimir@codesourcery.com> X-Mailer: Apple Mail (2.854) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00107.txt.bz2 On Nov 15, 2006, at 9:27 AM, Vladimir Prus wrote: > On Wednesday 15 November 2006 20:20, Jim Ingham wrote: >> Support for anonymous unions & structures is another of the "things >> we >> fixed but haven't submitted back"... We do pretty much what Vladimir >> suggests, though I use #anon#N for the varobj name: the choice >> doesn't >> much matter. We still return a blank expression (since that's really >> what the There's one other tricky bit 'caused by the fact that you >> might have more than one anonymous union or structure inside a >> structure. This wouldn't be a problem, but the varobj code tends to >> look up structure elements by name, which obviously won't work here. >> So you have to convert all the code that looks up structure elements >> to use the index rather than the name. > > Ah, I see. So this is not as easy change as I though. Yeah, I looked at the patch against our sources, and it is not hard, but it is annoyingly large. Mostly just a matter of having to push stuff through interfaces where it wasn't intended to go. I did it in two steps, because I didn't think about this complexity at first. So I did the trivial bit with just adding the anon. Then the major patch you can fetch from the Apple CVS with: cvs -q diff -p -r 1.83 -r 1.84 varobj.c > >> Another of the things we do in our varobj code for C++ is that we >> look >> up the dynamic type of objects (the same mechanism that "set print >> object on" uses, and the value & children we return are based on the >> dynamic type. As soon as you do that, you really do need a "give me >> the expression that can recreate this varobj" for child varobj's. >> Otherwise the MI client needs to get all these dynamic casts right to >> get down to the proper child, which is a bit of a pain. > > Good point. > >> But it's a generally useful command. We called it "var-info-path- >> expression" and given a varobj, it returns the expression that if >> evaluated would result in the same value. Xcode uses this for "show >> in separate window" actions in the debugger variable view. You can >> also use the to eliminate the "." for the anonymous structures or >> unions - though of course the MI client could do this too... > > In fact, I've posted a patch that ports -var-info-path-expression to > mainline > some time ago and we talked briefly with Daniel some time ago. > > I'll see if I can revive that patch. > Thanks... I just noticed that that code doesn't actually handle the anonymous structure case properly. You have to check if the structure name is anonymous and not emit an extra ".". Grrr... I haven't fixed it yet. Jim