From: Petr Sorfa <petrs@caldera.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb@sources.redhat.com
Subject: Re: dwarf2read.c:read_tag_string_type ()
Date: Mon, 15 Apr 2002 07:19:00 -0000 [thread overview]
Message-ID: <3CBAE381.97739EA8@caldera.com> (raw)
In-Reply-To: <20020413142826.A13608@nevyn.them.org>
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
next prev parent reply other threads:[~2002-04-15 14:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-13 5:36 Martin Baulig
2002-04-13 11:28 ` Daniel Jacobowitz
2002-04-15 7:19 ` Petr Sorfa [this message]
2002-04-15 7:22 ` Daniel Jacobowitz
2002-04-16 15:12 ` Jim Blandy
2002-04-16 15:25 ` Jim Blandy
2002-04-18 9:54 ` Martin Baulig
2002-04-19 12:03 ` Petr Sorfa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CBAE381.97739EA8@caldera.com \
--to=petrs@caldera.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox