dwarf2read.c:read_tag_string_type ()

dwarf2read.c:read_tag_string_type ()

[Martin Baulig]

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

Re: dwarf2read.c:read_tag_string_type ()

[Daniel Jacobowitz]

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

Re: dwarf2read.c:read_tag_string_type ()

[Petr Sorfa]

Hi Daniel,

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[124].

Petr
> 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

Re: dwarf2read.c:read_tag_string_type ()

[Daniel Jacobowitz]

On Mon, Apr 15, 2002 at 10:28:17AM -0400, Petr Sorfa wrote:
> Hi Daniel,
> 
> 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[124].

I'm not sure.  Daniel Berlin or Jim ought to have a better idea...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: dwarf2read.c:read_tag_string_type ()

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Mon, Apr 15, 2002 at 10:28:17AM -0400, Petr Sorfa wrote:
> > Hi Daniel,
> > 
> > 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[124].
> 
> I'm not sure.  Daniel Berlin or Jim ought to have a better idea...

Dan B. wrote me about some problems with the interface I proposed, and
I haven't written back to him.

Re: dwarf2read.c:read_tag_string_type ()

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Mon, Apr 15, 2002 at 10:28:17AM -0400, Petr Sorfa wrote:
> > Hi Daniel,
> > 
> > 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[124].
> 
> I'm not sure.  Daniel Berlin or Jim ought to have a better idea...

Probably the best way to make this happen would be to offer to work
with Dan B. on what he's doing, or start your own patch.  See
http://sources.redhat.com/ml/gdb/2002-02/msg00045.html for the
original description of the idea, and the recent discussion between me
and Dan B.

Re: dwarf2read.c:read_tag_string_type ()

[Martin Baulig]

Jim Blandy <jimb@redhat.com> writes:

> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Mon, Apr 15, 2002 at 10:28:17AM -0400, Petr Sorfa wrote:
> > > Hi Daniel,
> > > 
> > > 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[124].
> > 
> > I'm not sure.  Daniel Berlin or Jim ought to have a better idea...
> 
> Probably the best way to make this happen would be to offer to work
> with Dan B. on what he's doing, or start your own patch.  See
> http://sources.redhat.com/ml/gdb/2002-02/msg00045.html for the
> original description of the idea, and the recent discussion between me
> and Dan B.

I may be able to help with this as well, but unfortunately I won't
have any time for the next 3-4 weeks. However, I really need this for
my C# debugging support.

-- 
Martin Baulig
martin@gnome.org

Re: dwarf2read.c:read_tag_string_type ()

[Petr Sorfa]

Hi Martin and Jim,

I can start focusing my attention to this next week (April 23 onwards).
I'll contact Daniel Berlin then for more discussions.

Petr
> Jim Blandy <jimb@redhat.com> writes:
> 
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > On Mon, Apr 15, 2002 at 10:28:17AM -0400, Petr Sorfa wrote:
> > > > Hi Daniel,
> > > >
> > > > 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[124].
> > >
> > > I'm not sure.  Daniel Berlin or Jim ought to have a better idea...
> >
> > Probably the best way to make this happen would be to offer to work
> > with Dan B. on what he's doing, or start your own patch.  See
> > http://sources.redhat.com/ml/gdb/2002-02/msg00045.html for the
> > original description of the idea, and the recent discussion between me
> > and Dan B.
> 
> I may be able to help with this as well, but unfortunately I won't
> have any time for the next 3-4 weeks. However, I really need this for
> my C# debugging support.
> 
> --
> Martin Baulig
> martin@gnome.org