From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16141 invoked by alias); 9 Jan 2004 15:30:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16134 invoked from network); 9 Jan 2004 15:30:17 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 9 Jan 2004 15:30:17 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id B1C0C1A440D; Fri, 9 Jan 2004 10:29:04 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16382.51392.626691.65583@localhost.redhat.com> Date: Fri, 09 Jan 2004 15:30:00 -0000 To: mec.gnu@mindspring.com (Michael Elizabeth Chastain) Cc: ezannoni@redhat.com, gdb@sources.redhat.com Subject: Re: FORTRAN_HACK macro? In-Reply-To: <20040108232505.E9A384B35A@berman.michael-chastain.com> References: <20040108232505.E9A384B35A@berman.michael-chastain.com> X-SW-Source: 2004-01/txt/msg00122.txt.bz2 Michael Elizabeth Chastain writes: > Beats me. Here's some fact-crumbs: > > dwarf2read.c was not in gdb 4.16. > dwarf2read.c was in gdb 4.17, dated 1998-01-28 > 1998-01-28 version already has FORTRAN_HACK > code around FORTRAN_HACK is about the same as it is today > ChangeLog-96 says dwarf2read.c introduced on 1996-07-19. > > grepping on 'read_array_type' in the ChangeLogs turns up: > > 1996-12-01: > > (dwarf_read_array_type): Handle variable length arrays. > Use lookup_pointer_type instead of handcrafting a type. > Create array type only if a DW_TAG_subrange_type was found. > > 1997-01-25: > (read_array_type): Renamed from dwarf_read_array_type. > Default upper array bound to describe an array with unspecified > length. > Create array types in backwards order, as dwarf2 puts out the array > dimensions from left to right. > > 1998-01-28: > > (read_array_type): Fix langauge test. > > If the FORTRAN_HACK was in the 1996-07-19 version then I would guess > that it is an unimplemented stub and can be killed/replaced easily. yes I think it was there since the first incarnation of the file. It hasn't been touched except for that one in 96. > > If it was added after 1996-07-19 then someone was trying to do > something. > I don't think it was. elena > Michael C