From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 959 invoked by alias); 31 Jul 2007 14:29:57 -0000 Received: (qmail 949 invoked by uid 22791); 31 Jul 2007 14:29:56 -0000 X-Spam-Check-By: sourceware.org Received: from jess.glam.ac.uk (HELO jess.glam.ac.uk) (193.63.147.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 31 Jul 2007 14:29:53 +0000 Received: from j228-gm.comp.glam.ac.uk ([193.63.148.84]) by jess.glam.ac.uk with esmtp (Exim 3.35 #1) id 1IFsio-0000oh-00; Tue, 31 Jul 2007 15:29:14 +0100 Received: from gaius by j228-gm.comp.glam.ac.uk with local (Exim 4.63) (envelope-from ) id 1IFsdA-00046B-BR; Tue, 31 Jul 2007 15:23:24 +0100 From: Gaius Mulley To: Jim Blandy Cc: Eli Zaretskii , deuling@de.ibm.com, gdb-patches@sources.redhat.com Subject: Re: [PATCH] Unbounded array support implemented (for Modula-2) References: <874pjs57zg.fsf@j228-gm.comp.glam.ac.uk> <46A847CE.7030907@de.ibm.com> <87ir866ocg.fsf@j228-gm.comp.glam.ac.uk> <87r6mqif61.fsf@j228-gm.comp.glam.ac.uk> Date: Tue, 31 Jul 2007 16:47:00 -0000 In-Reply-To: (Jim Blandy's message of "Mon, 30 Jul 2007 17:13:18 -0700") Message-ID: <871weops83.fsf@j228-gm.comp.glam.ac.uk> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00333.txt.bz2 Jim Blandy writes: > I'd like to see the tests go in, too. I'm not sure the approach they > take is one we'd like to follow in future code, though. > > I'm inferring from the test and from the Modula-2 code in GDB that > the debugging information GCC emits for unbounded arrays claims that > they're a structure of the form: > > struct { > char *_m2_contents; > int _m2_high; > }; > > Then, GDB's Modula-2 code recognizes this structure as a special case, > and treats it as an array. > > It seems to me the tests should go ahead and require a Modula-2 > compiler, compile a real Modula-2 program, and exit with 'unsupported' > if there's no Modula-2 compiler present. > > It's a shame that the debugging info doesn't actually treat these > Modula-2 arrays as arrays. The 'proper' DWARF representation would be > a DW_TAG_array_type die with a DW_TAG_subrange_type for the variable > index whose a DW_AT_upper_bound attribute is some DWARF expression > like: > > DW_OP_push_object_address DW_OP_lit4 DW_OP_plus DW_OP_deref > > to compute the upper bound of the array. > > Then GDB would need to learn to understand these things. In a > quick-and-dirty implementation, the DWARF reader would turn the DWARF > above into arrays whose index subrange types used a new > BOUND_BY_DESCRIPTOR value for 'enum array_bound_type', ignoring the > DWARF expression. Then language-specific code would have to handle > those as a special case. > > The best implementation would be to have a new BOUND_COMPUTED style of > bound, and have the 'loc' union in 'struct field' point to a structure > like this: > > struct computed_bound { > /* Return the value of a computed bound. V is the array value whose > bound we're computing; CB is a pointer to this structure. */ > LONGEST (*compute_bound (struct computed_bound *cb, struct value *v)); > > /* Data to be used by the COMPUTE_BOUND function. */ > void *data; > }; > > The DWARF reader would create these when it sees arrays with upper > bounds that are expressions, making DATA point to the expression and > COMPUTE_BOUND point to a function that uses dwarf2expr.h to evaluate > the expression. > > Then the generic GDB array code could handle Modula-2 variable arrays > (or anything else that the DWARF described accurately). > > This isn't exactly a one-weekend project, though. Hi Jim, thank you for the various pointers (re: dwarf2 opcodes, subranges and unbounded arrays - I also note your --fixme-- in the dwarf2read code) - I wonder whether it might be better to hold off applying the patch and attempt to solve the problem properly using the COMPUTE_BOUND method explained above. I'm willing to attempt this - its always more satisfying solving a problem correctly :-) and in theory this method might be useful for Pascal as well. It should also mean ISO M2 multidimensional unbounded arrays will be easier to implement. regards, Gaius