From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20481 invoked by alias); 30 Jun 2005 22:23:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20456 invoked by uid 22791); 30 Jun 2005 22:23:29 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 30 Jun 2005 22:23:29 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1Do7RP-00034g-Io; Thu, 30 Jun 2005 18:23:27 -0400 Date: Thu, 30 Jun 2005 22:23:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: Start Fortran support for variable objects. Message-ID: <20050630222327.GA11630@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17091.4780.953681.620094@farnswood.snap.net.nz> <20050630025323.GA26397@nevyn.them.org> <17091.46378.720749.411474@farnswood.snap.net.nz> <20050630131454.GA8241@nevyn.them.org> <17092.25345.897986.957028@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17092.25345.897986.957028@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00394.txt.bz2 On Fri, Jul 01, 2005 at 09:24:17AM +1200, Nick Roberts wrote: > > Well, that's what was SUPPOSED to happen, anyway. > > > > <1>: Abbrev Number: 4 (DW_TAG_array_type) > > DW_AT_sibling : > > DW_AT_type : > > <2>: Abbrev Number: 5 (DW_TAG_subrange_type) > > DW_AT_type : > > DW_AT_upper_bound : 4 > > This is Dwarf output? Using something like readelf? (I'm just guessing). That's right. > > I would have expected there to be a lower bound also... but there just > > isn't. Your patch is more or less OK. Let me reply to it to pick up > > some formatting comments. > > For future reference, are you saying that there should be some internal > representation for arrays that GDB uses which should describe the offset; > that this could be used to print the variable object without reference > to the language; and that this method should work with other unsupported > (by varobj.c) languages like Pascal, for example? I'd like that. Varobj shouldn't need to know this; the rest of GDB should be able to provide it. But that's just my design instinct speaking. It may not be worth the trouble putting all the pieces together. -- Daniel Jacobowitz CodeSourcery, LLC