This is the mail archive of the
mailing list for the GDB project.
Re: dwarf2read.c:read_tag_string_type ()
When can we expect the new location expression handler? I have several
patches waiting to be altered from my own DWARF3 location expression
handler. These patches include support for dynamic arrays (lower and
upper bounds, stride), arguments (dynamic), associated attributes and
allocated attributes . Basically a fair chunk of everything that uses
DW_AT_location with DW_FORM_block.
> 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