From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14246 invoked by alias); 31 Jul 2007 00:13:23 -0000 Received: (qmail 14237 invoked by uid 22791); 31 Jul 2007 00:13:23 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 31 Jul 2007 00:13:21 +0000 Received: (qmail 30197 invoked from network); 31 Jul 2007 00:13:19 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Jul 2007 00:13:19 -0000 To: Gaius Mulley 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> From: Jim Blandy Date: Tue, 31 Jul 2007 03:01:00 -0000 In-Reply-To: <87r6mqif61.fsf@j228-gm.comp.glam.ac.uk> (Gaius Mulley's message of "Mon, 30 Jul 2007 07:22:46 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (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/msg00319.txt.bz2 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.