dwarf2read.c:read_tag_string_type ()

[Martin Baulig <martin@gnome.org>]

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