From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25604 invoked by alias); 26 Feb 2006 05:37:10 -0000 Received: (qmail 25596 invoked by uid 22791); 26 Feb 2006 05:37:09 -0000 X-Spam-Check-By: sourceware.org Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.205) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 26 Feb 2006 05:37:07 +0000 Received: by xproxy.gmail.com with SMTP id i29so425898wxd for ; Sat, 25 Feb 2006 21:37:05 -0800 (PST) Received: by 10.70.99.19 with SMTP id w19mr4685572wxb; Sat, 25 Feb 2006 21:37:05 -0800 (PST) Received: by 10.70.125.17 with HTTP; Sat, 25 Feb 2006 21:37:05 -0800 (PST) Message-ID: <8f2776cb0602252137q7e716ffaibd7b88eeb0d16e43@mail.gmail.com> Date: Sun, 26 Feb 2006 05:44:00 -0000 From: "Jim Blandy" To: "Gaius Mulley" Subject: Re: Enhanced language support for Modula-2 Cc: gdb-patches@sources.redhat.com In-Reply-To: <87wtfjfwmu.fsf@j228-gm.comp.glam.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <87vevg9puv.fsf@j228-gm.comp.glam.ac.uk> <8f2776cb0602151619w5fd8f043u3e7227e27f3567a9@mail.gmail.com> <20060220150513.GB14155@nevyn.them.org> <8f2776cb0602201322o3791841dv2916e53181e9f308@mail.gmail.com> <87lkw5qaa9.fsf@j228-gm.comp.glam.ac.uk> <8f2776cb0602211055t572223ecs93e37d5575a31ce@mail.gmail.com> <87wtfjfwmu.fsf@j228-gm.comp.glam.ac.uk> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00477.txt.bz2 On 25 Feb 2006 12:31:05 +0000, Gaius Mulley wrote: > I guess the Modula-2 mode can use a different method. Would it be > allowable for me to extend the > > #define TYPE_FLAG_xxx > > sequence (currently bits 0..15 are used). So for example: > > #define TYPE_FLAG_LANG_CHAR (1 << 16) > > and set this flag if we see DW_ATE_signed_char or > DW_ATE_unsigned_char. Later in the Modula-2 language section this bit > could be tested and the appropriate action taken. Obviously I'd need > to set this bit in stabsread.c as well. This would also allow Pascal > to utilise CHAR rather than see a tiny integer. If Modula-2 has a genuinely distinct character type, then I think TYPE_CODE_CHAR is the right type for you to use. It's just that it isn't for C. So the code in dwarf2read.c needs to choose the type code for a given DWARF base type based on the language of the compilation unit that contains the die. I think you'll need to test cu->language, and set the type code appropriately in each case. That may sound icky, but given that DWARF has decided to represent different languages' types with a unified set of die tags, it seems the reasonable way to go. If, over time, read_base_type gets really complicated due to this sort of thing, then we could always have some sort of language-specific hook function. But since GDB uses the same approach to types that Dwarf does --- a unified set of type codes used by all the languages --- we only really have to attend to the cases where GDB's mappings are different from DWARF's, so I think it should be okay for now.