From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15300 invoked by alias); 13 Apr 2002 12:36:27 -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 15282 invoked from network); 13 Apr 2002 12:36:25 -0000 Received: from unknown (HELO mx04.nexgo.de) (151.189.8.80) by sources.redhat.com with SMTP; 13 Apr 2002 12:36:25 -0000 Received: from einstein.home-of-linux.org (dialin-212-144-185-123.arcor-ip.net [212.144.185.123]) by mx04.nexgo.de (Postfix) with ESMTP id E348D37D4C for ; Sat, 13 Apr 2002 14:36:24 +0200 (CEST) Received: by einstein.home-of-linux.org (Postfix, from userid 1001) id 2817E20010; Sat, 13 Apr 2002 14:34:33 +0200 (CEST) To: gdb@sources.redhat.com Subject: dwarf2read.c:read_tag_string_type () From: Martin Baulig Date: Sat, 13 Apr 2002 05:36:00 -0000 Message-ID: <867knbeq06.fsf@einstein.home-of-linux.org> User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00230.txt.bz2 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 ? When doing this, can we also make it interpret the DW_AT_data_location (added in the DWARF 3 draft) ? * * * I'm not sure whether that's the correct way to do it, but I want to use the DW_TAG_string_type for C# strings - they're basically just UTF-16 strings, but their length and data location (ie. the location where the actual UTF-16 data starts) is dynamically created by the JIT engine, so the debugger must use a location description to get this info. For C#, we also have the problem that different JIT engines implement strings in a different way internally - so for GDB a C# string is an opaque object and it must use the information in the symbol file to find out how to get it's length and UTF-16 data. -- Martin Baulig martin@gnome.org