From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23494 invoked by alias); 10 Apr 2007 15:31:04 -0000 Received: (qmail 23475 invoked by uid 22791); 10 Apr 2007 15:31:03 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Apr 2007 16:30:46 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id A8E554B267; Tue, 10 Apr 2007 10:30:45 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 807A24B262; Tue, 10 Apr 2007 10:30:45 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HbIIu-0003JG-3W; Tue, 10 Apr 2007 11:30:44 -0400 Date: Tue, 10 Apr 2007 15:31:00 -0000 From: Daniel Jacobowitz To: Denis PILAT Cc: gdb-patches Subject: Re: [RFC] DW_AT_type missing from DW_TAG_subrange_type Message-ID: <20070410153043.GC10890@caradoc.them.org> Mail-Followup-To: Denis PILAT , gdb-patches References: <4612556C.1080709@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4612556C.1080709@st.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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-04/txt/msg00088.txt.bz2 On Tue, Apr 03, 2007 at 03:23:56PM +0200, Denis PILAT wrote: > For the global variable declared like that > int array[] = {1, 2, 3, 4}; > the dwarf information generated by our specific compiler is missing DW_AT_type > missing from DW_TAG_subrange_type. > > Usually in dwarf2 information (ie like the bellow example for gcc4 under > linux), the DW_AT_type exists for subranges : > > < 175 (0xaf) > DW_TAG_array_type > | DW_AT_sibling : < 191 (0xbf) > > | DW_AT_type : < 168 (0xa8) > > `-------------------------- > < 184 (0xb8) > DW_TAG_subrange_type > * | DW_AT_type : < 191 (0xbf) >* <<<<<-------- missing from my elf > file > | DW_AT_upper_bound : DW_AT_upper_bound(DW_FORM_data1) : 3 > `-------------------------- Conveniently, the DWARF 3 standard specifies what this means (DWARF 2 may also; I didn't check). From the standard: > If the subrange entry has no type attribute describing the basis type, > the basis type is assumed to be the same as the object described by > the lower bound attribute (if it references an object). If there is no > lower bound attribute, or that attribute does not reference an object, > the basis type is the type of the upper bound or count attribute (if > either of them references an object). If there is no upper bound or > count attribute, or neither references an object, the type is assumed > to be the same type, in the source language of the compilation unit > containing the subrange entry, as a signed integer with the same size > as an address on the target machine. Since we do not handle objects for bounds yet, we're only interested in that last case. So, we should use an integer type the size of an address. Try using dwarf_base_type (DW_ATE_signed, TARGET_ADDR_BIT / 8, cu)? That function is, in fact, very buggy. We should fix it. It has hardcoded sizes of 1, 2, 4 for char, short, int and doesn't support long long at all. > I'm also wondering about the code: > base_type = die_type (die, cu); > if (base_type == NULL) > { > complaint (&symfile_complaints, > _("DW_AT_type missing from DW_TAG_subrange_type")); > return; > } > It seems we'll never have (base_type == NULL). Am I right ? > May be it's time to remove that as well. The complaints seems to be in a better > place in my patch. You're right; please do. -- Daniel Jacobowitz CodeSourcery