From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30156 invoked by alias); 4 Jul 2005 03:49:16 -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 30141 invoked by uid 22791); 4 Jul 2005 03:49:11 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 04 Jul 2005 03:49:11 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1DpHxB-0001mh-Fn; Sun, 03 Jul 2005 23:49:05 -0400 Date: Mon, 04 Jul 2005 03:49:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Wu Zhou , gdb-patches@sources.redhat.com Subject: Re: PATCH: Start Fortran support for variable objects. Message-ID: <20050704034904.GA5802@nevyn.them.org> Mail-Followup-To: Nick Roberts , Wu Zhou , gdb-patches@sources.redhat.com References: <17091.4780.953681.620094@farnswood.snap.net.nz> <20050630131809.GB8241@nevyn.them.org> <17092.28833.284587.118362@farnswood.snap.net.nz> <17092.51062.559020.560618@farnswood.snap.net.nz> <20050703161706.GA13289@nevyn.them.org> <17096.30621.21570.307217@farnswood.snap.net.nz> <20050703234725.GA28151@nevyn.them.org> <17096.37817.638887.840041@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17096.37817.638887.840041@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00039.txt.bz2 On Mon, Jul 04, 2005 at 01:41:13PM +1200, Nick Roberts wrote: > > > > First of all, never reference ->main_type - see above for the right way > > > > to get the low bound. An even better way (it seems) is to call > > > > get_discrete_bounds. Take a look at value_subscript for an example. > > > > > > Better than TYPE_LOW_BOUND? > > > > I suppose. I don't know which one is preferred; some day, someone > > should go through and clean them all up to be consistent. I'm fine > > with either choice. > > To keep things simple I've used TYPE_LOW_BOUND. I've tested with the examples > I've posted before and it works. Presumably there should also be a test case, > so I'll create one for mi-var-child.exp and mi2-var-child.exp (you still > haven't approved my patch for mi2-cmd-stack.exp (28 Jun 2005 01:53:52 +1200). You posted nothing to gdb-patches on June 27th, 28th, or 29th (except for the first version of this patch). I vaguely remember seeing a patch on gdb@ when Mark complained about your introducing regressions. But if you'd like it approved, please post it to the patches list; I am methodical about processing gdb-patches mail because it has a clearly defined request-reply format, and gdb@ discussions tend to wander off on tangents (like that one did). BTW, found the patch in the archives - the changelog entry is for the wrong file. Also, can we just remove the failing test, instead of adding new tests to mi2? We really need to get a coherent story together on what "is" mi2, but I don't think we need to add tests for new commands to it. > 2005-06-30 Nick Roberts > > * varobj.c (varobj_list_children): Allow non-zero offsets for > languages like Fortran. Retcode is unused. Can't we get here with struct types? In which case this will blow up: > + j = i + TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type)); > + > /* check if child exists, if not create */ > - name = name_of_child (var, i); > + name = name_of_child (var, j); > child = child_exists (var, name); > if (child == NULL) > - child = create_child (var, i, name); > + child = create_child (var, j, name); > > *((*childlist) + i) = child; > } Also, I'm beginning to wonder if you're doing this in the right place. Not that it matters a whole lot, but index is 0-based in every other case, including for structs. Maybe the children of arr(4) should be arr.0 == arr(1), arr.1 == arr(2), arr.2 == arr(3), arr.3 == arr(4). Then you'd add the lower bound in c_value_of_child. Does that work? Do you have an opinion on which is "more right"? -- Daniel Jacobowitz CodeSourcery, LLC