From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32059 invoked by alias); 25 Nov 2007 22:11:06 -0000 Received: (qmail 32050 invoked by uid 22791); 25 Nov 2007 22:11:05 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 25 Nov 2007 22:10:59 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lAPMAvUb014666 for ; Sun, 25 Nov 2007 17:10:57 -0500 Received: from pobox.stuttgart.redhat.com (pobox.stuttgart.redhat.com [172.16.2.10]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAPMAgYH001053 for ; Sun, 25 Nov 2007 17:10:42 -0500 Received: from host0.dyn.jankratochvil.net (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.stuttgart.redhat.com (8.13.1/8.13.1) with ESMTP id lAPMAeKN013881 for ; Sun, 25 Nov 2007 17:10:41 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.1/8.14.1) with ESMTP id lAPMAdeH007399; Sun, 25 Nov 2007 23:10:39 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.1/8.14.1/Submit) id lAPMAbK8007398; Sun, 25 Nov 2007 23:10:37 +0100 Date: Sun, 25 Nov 2007 22:11:00 -0000 From: Jan Kratochvil To: gdb-patches@sources.redhat.com Cc: Daniel Jacobowitz , Carlos Eduardo Seo Subject: Re: [patch] XLF Fortran: Remove an inappropriate complaint [Re: XLF Fortran arrays test] Message-ID: <20071125221037.GA6297@host0.dyn.jankratochvil.net> References: <20071116032002.GA9885@host0.dyn.jankratochvil.net> <473DD96D.5020900@linux.vnet.ibm.com> <20071116194448.GA32395@host0.dyn.jankratochvil.net> <4741A077.9050900@linux.vnet.ibm.com> <20071123015957.GA3202@host0.dyn.jankratochvil.net> <20071123021120.GA11797@host0.dyn.jankratochvil.net> <20071123163125.GA23275@host0.dyn.jankratochvil.net> <4747086C.3070100@linux.vnet.ibm.com> <20071123172104.GA23776@host0.dyn.jankratochvil.net> <20071125145555.GB30778@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071125145555.GB30778@caradoc.them.org> User-Agent: Mutt/1.5.17 (2007-11-01) 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-11/txt/msg00475.txt.bz2 On Sun, 25 Nov 2007 15:55:55 +0100, Daniel Jacobowitz wrote: > On Fri, Nov 23, 2007 at 06:21:04PM +0100, Jan Kratochvil wrote: > > On Fri, 23 Nov 2007 18:05:48 +0100, Carlos Eduardo Seo wrote: > > ... > > > During symbol reading, DW_AT_type missing from DW_TAG_subrange_type. > > > > This code was there already before my changes. And the XLF output really > > misses DW_AT_type for DW_TAG_subrange_type. But it should be correct: > > http://dwarf.freestandards.org/Dwarf3.pdf > > 5.12 Subrange Type Entries > > The subrange entry may have a DW_AT_type attribute to describe the type > > of object, called the basis type, of whose values this subrange is > > a subset. > > > > "may have" should not produce a `complaint' category message as it is not > > a standard violation. > > Here's the rest of what the standard has to say: > > == > 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. > == > > It looks to me like (before your other patches?) we do not support > the bounds or count referring to objects. Before my patches http://sources.redhat.com/ml/gdb-patches/2007-11/msg00438.html the code supported for the bounds DW_FORM_sdata, DW_FORM_udata, DW_FORM_data{1,2,4,8} and after my patches it supports the bounds/count DW_FORM_block{,1,2,4} To reference `object' it would have to support DW_FORM_reF* but this form is still not supported. > The code below the > complaint is creating a signed integer type the size of an address. > So your patch is OK. Thanks. I see now my point is wrong. The code still violates (notwithstanding of any of my Fortran patches) the DWARF standard as it ignores DW_AT_lower_bound/DW_AT_upper_bound/DW_AT_count with DW_FORM_ref* which may specify the intended type through another DIE (as can be seen in DWARF3 D.2.2). Sorry, Jan