From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2383 invoked by alias); 13 Apr 2002 18:28:14 -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 2374 invoked from network); 13 Apr 2002 18:28:10 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 13 Apr 2002 18:28:10 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16wSGA-0003dG-00 for ; Sat, 13 Apr 2002 14:28:26 -0400 Date: Sat, 13 Apr 2002 11:28:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: dwarf2read.c:read_tag_string_type () Message-ID: <20020413142826.A13608@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <867knbeq06.fsf@einstein.home-of-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867knbeq06.fsf@einstein.home-of-linux.org> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00233.txt.bz2 On Sat, Apr 13, 2002 at 02:34:33PM +0200, Martin Baulig wrote: > Hi, > > in dwarf2read.c, read_tag_string_type() reads the DW_AT_string_length > attribute as DW_UNSND(), but according to the DWARF 2 spec, this is a > location description. > > >From the DWARF 2 spec: > > ===== > 5.8 String Type Entries > A ``string'' is a sequence of characters that have specific semantics > and operations that separate them from arrays of characters. Fortran > is one of the languages that has a string type. A string type is > represented by a debugging information entry with the tag > DW_TAG_string_type. If a name has been given to the string type in > the source program, then the corresponding string type entry has a > DW_AT_name attribute whose value is a null-terminated string > containing the string type name as it appears in the source > program. The string type entry may have a DW_AT_string_length > attribute whose value is a location description yielding the location > where the length of the string is stored in the program. The string > type entry may also have a DW_AT_byte_size attribute, whose constant > value is the size in bytes of the data to be retrieved from the > location referenced by the string length attribute. If no byte size > attribute is present, the size of the data to be retrieved is the same > as the size of an address on the target machine. If no string length > attribute is present, the string type entry may have a DW_AT_byte_size > attribute, whose constant value is the length in bytes of the string. > ==== > > Is there any reason for doing this (ie. some compiler is incorrectly > emitting this attribute) or can this be fixed ? My guess is that it can be fixed. GCC doesn't even emit DW_AT_string_length. This is waiting on improved location expression support (coming soon). -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer