[PATCH] DWARF support for .debug_loc offsets

[PATCH] DWARF support for .debug_loc offsets

[Petr Sorfa]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

Hi,

This patch provides support for offsets into .debug_loc.

The patch does not include .debug_loc support in read_tag_string_type()
as the DW_AT_string_length attribute is currently being misused by GCC
(it uses it to hold the length, rather than the location to the length)
and GDB supports the incorrect form.

There is a second part of this patch which is dependent on FORTRAN95
support of modules and will be released later.

2002-07-11 Petr Sorfa (petrs@caldera.com)

        *  dwarf2read.c (dwarf2_invalid_attrib_class): New
           complaint for invalid attribute class or form.
           (read_func_scope): DW_AT_frame_base
           attribute now supports .debug_loc offsets.
           (dwarf2_add_member_fn): DW_AT_vtable_elem_location
           attribute now supports .debug_loc offsets.
           (read_common_block): DW_AT_location attribute
           now supports .debug_loc offsets.
           (read_partial_die): DW_AT_location attribute now
           supports .debug_loc offsets.
           (new_symbol): DW_AT_external now supports
           .debug_loc offsets.

[-- Attachment #2: debug_loc_no_dep.patch --]
[-- Type: text/plain, Size: 9495 bytes --]

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.60
diff -c -p -r1.60 dwarf2read.c
*** dwarf2read.c	22 Jun 2002 00:05:59 -0000	1.60
--- dwarf2read.c	11 Jul 2002 16:11:08 -0000
*************** static struct complaint dwarf2_macro_spa
*** 658,663 ****
--- 658,667 ----
  {
    "macro definition contains spaces in formal argument list:\n`%s'", 0, 0
  };
+ static struct complaint dwarf2_invalid_attrib_class =
+ {
+   "invalid attribute class or form for '%s' in '%s'", 0, 0
+ };
  
  /* local function prototypes */
  
*************** read_func_scope (struct die_info *die, s
*** 1870,1876 ****
    attr = dwarf_attr (die, DW_AT_frame_base);
    if (attr)
      {
!       CORE_ADDR addr = decode_locdesc (DW_BLOCK (attr), objfile, cu_header);
        if (isderef)
  	complain (&dwarf2_unsupported_at_frame_base, name);
        else if (isreg)
--- 1874,1904 ----
    attr = dwarf_attr (die, DW_AT_frame_base);
    if (attr)
      {
!       CORE_ADDR addr;
! 
!       /* Support the .debug_loc offsets */
!       if (attr->form == DW_FORM_block1
!                        || attr->form == DW_FORM_block2
!                        || attr->form == DW_FORM_block4
!                        || attr->form == DW_FORM_block)
!         {
!           addr = decode_locdesc (DW_BLOCK (attr), objfile, cu_header);
!         }
!       else if (attr->form == DW_FORM_data4 || attr->form == DW_FORM_data8)
!         {
!           int bytes_read;
! 
!           /* Offset from .debug_loc */
!           addr = read_address (objfile->obfd,
!                    (char *)(DW_UNSND (attr) + dwarf_loc_offset),
!                    cu_header, &bytes_read);
!         }
!       else
!         {
!           complain (&dwarf2_invalid_attrib_class, "DW_AT_frame_base", name);
!           addr = 0;
!         }
!     
        if (isderef)
  	complain (&dwarf2_unsupported_at_frame_base, name);
        else if (isreg)
*************** dwarf2_add_member_fn (struct field_info 
*** 2348,2354 ****
    /* Get index in virtual function table if it is a virtual member function.  */
    attr = dwarf_attr (die, DW_AT_vtable_elem_location);
    if (attr)
!     fnp->voffset = decode_locdesc (DW_BLOCK (attr), objfile, cu_header) + 2;
  }
  
  /* Create the vector of member function fields, and attach it to the type.  */
--- 2376,2405 ----
    /* Get index in virtual function table if it is a virtual member function.  */
    attr = dwarf_attr (die, DW_AT_vtable_elem_location);
    if (attr)
!     {
!       /* Support the .debug_loc offsets */
!       if (attr->form == DW_FORM_block1
!                        || attr->form == DW_FORM_block2
!                        || attr->form == DW_FORM_block4
!                        || attr->form == DW_FORM_block)
!         {
!           fnp->voffset = decode_locdesc (DW_BLOCK (attr), objfile, cu_header) + 2;
!         }
!       else if (attr->form == DW_FORM_data4 || attr->form == DW_FORM_data8)
!         {
!           int bytes_read;
! 
!           /* Offset from .debug_loc */
!           fnp->voffset = read_address (objfile->obfd,
!                            (char *)(DW_UNSND (attr) + dwarf_loc_offset),
!                            cu_header, &bytes_read) + 2;
!         }
!       else
!         {
!           complain (&dwarf2_invalid_attrib_class, "DW_AT_vtable_elem_location",
!                     fieldname);
!         }
!    }
  }
  
  /* Create the vector of member function fields, and attach it to the type.  */
*************** read_common_block (struct die_info *die,
*** 2812,2818 ****
    attr = dwarf_attr (die, DW_AT_location);
    if (attr)
      {
!       base = decode_locdesc (DW_BLOCK (attr), objfile, cu_header);
      }
    if (die->has_children)
      {
--- 2863,2890 ----
    attr = dwarf_attr (die, DW_AT_location);
    if (attr)
      {
!       /* Support the .debug_loc offsets */
!       if (attr->form == DW_FORM_block1
!                        || attr->form == DW_FORM_block2
!                        || attr->form == DW_FORM_block4
!                        || attr->form == DW_FORM_block)
!         {
!           base = decode_locdesc (DW_BLOCK (attr), objfile, cu_header);
!         }
!       else if (attr->form == DW_FORM_data4 || attr->form == DW_FORM_data8)
!         {
!           int bytes_read;
! 
!           /* Offset from .debug_loc */
!           base = read_address (objfile->obfd,
!                    (char *)(DW_UNSND (attr) + dwarf_loc_offset),
!                    cu_header, &bytes_read);
!         }
!       else
!         {
!           complain (&dwarf2_invalid_attrib_class, "DW_AT_location",
!                     "common block member");
!         }
      }
    if (die->has_children)
      {
*************** read_partial_die (struct partial_die_inf
*** 3458,3464 ****
  	  part_die->highpc = DW_ADDR (&attr);
  	  break;
  	case DW_AT_location:
! 	  part_die->locdesc = DW_BLOCK (&attr);
  	  break;
  	case DW_AT_language:
  	  part_die->language = DW_UNSND (&attr);
--- 3530,3557 ----
  	  part_die->highpc = DW_ADDR (&attr);
  	  break;
  	case DW_AT_location:
!           /* Support the .debug_loc offsets */
!           if (attr.form == DW_FORM_block1
!                        || attr.form == DW_FORM_block2
!                        || attr.form == DW_FORM_block4
!                        || attr.form == DW_FORM_block)
!             {
! 	       part_die->locdesc = DW_BLOCK (&attr);
!             }
!           else if (attr.form == DW_FORM_data4 || attr.form == DW_FORM_data8)
!             {
!               /* Offset from .debug_loc */
!               int bytes_read;
!               
!               part_die->locdesc = (struct dwarf_block *)read_address (abfd,
!                                        (char *)(DW_UNSND (&attr) + dwarf_loc_offset),
!                                        cu_header, &bytes_read);
!             }
!           else
!             {
!               complain (&dwarf2_invalid_attrib_class, "DW_AT_location",
!                         "partial symbol information");
!             }
  	  break;
  	case DW_AT_language:
  	  part_die->language = DW_UNSND (&attr);
*************** new_symbol (struct die_info *die, struct
*** 4606,4613 ****
  	      attr2 = dwarf_attr (die, DW_AT_external);
  	      if (attr2 && (DW_UNSND (attr2) != 0))
  		{
! 		  SYMBOL_VALUE_ADDRESS (sym) =
! 		    decode_locdesc (DW_BLOCK (attr), objfile, cu_header);
  		  add_symbol_to_list (sym, &global_symbols);
  
  		  /* In shared libraries the address of the variable
--- 4699,4729 ----
  	      attr2 = dwarf_attr (die, DW_AT_external);
  	      if (attr2 && (DW_UNSND (attr2) != 0))
  		{
!                   /* Support the .debug_loc offsets */
!                   if (attr->form == DW_FORM_block1
!                        || attr->form == DW_FORM_block2
!                        || attr->form == DW_FORM_block4
!                        || attr->form == DW_FORM_block)
!                     {
! 		      SYMBOL_VALUE_ADDRESS (sym) =
! 		        decode_locdesc (DW_BLOCK (attr), objfile, cu_header);
!                     }
!                   else if (attr->form == DW_FORM_data4
!                            || attr->form == DW_FORM_data8)
!                     {
!                       int bytes_read;
! 
!                       /* Offset from .debug_loc */
! 		      SYMBOL_VALUE_ADDRESS (sym) =
!                         read_address (objfile->obfd,
!                           (char *)(DW_UNSND (attr) + dwarf_loc_offset),
!                           cu_header, &bytes_read);
!                     }
!                   else
!                     {
!                       complain (&dwarf2_invalid_attrib_class, "DW_AT_location",
!                                 "external variable");
!                     }
  		  add_symbol_to_list (sym, &global_symbols);
  
  		  /* In shared libraries the address of the variable
*************** new_symbol (struct die_info *die, struct
*** 4630,4637 ****
  		}
  	      else
  		{
! 		  SYMBOL_VALUE (sym) = addr =
! 		    decode_locdesc (DW_BLOCK (attr), objfile, cu_header);
  		  add_symbol_to_list (sym, list_in_scope);
  		  if (optimized_out)
  		    {
--- 4746,4777 ----
  		}
  	      else
  		{
!                   /* Support the .debug_loc offsets */
!                   if (attr->form == DW_FORM_block1
!                        || attr->form == DW_FORM_block2
!                        || attr->form == DW_FORM_block4
!                        || attr->form == DW_FORM_block)
!                     {
! 		      SYMBOL_VALUE (sym) = addr =
! 		        decode_locdesc (DW_BLOCK (attr), objfile, cu_header);
!                     }
!                   else if (attr->form == DW_FORM_data4
!                            || attr->form == DW_FORM_data8)
!                     {
!                       int bytes_read;
! 
!                       /* Offset from .debug_loc */
! 		      SYMBOL_VALUE (sym) = addr =
!                         read_address (objfile->obfd,
!                           (char *)(DW_UNSND (attr) + dwarf_loc_offset),
!                           cu_header, &bytes_read);
!                     }
!                   else
!                     {
!                       complain (&dwarf2_invalid_attrib_class, "DW_AT_location",
!                                 "external variable");
!                       addr = 0;
!                     }
  		  add_symbol_to_list (sym, list_in_scope);
  		  if (optimized_out)
  		    {

Re: [PATCH] DWARF support for .debug_loc offsets

[Jim Blandy]

A procedural nit: putting "PATCH" in the subject line means by
convention that you've committed, or are about to commit, the patch in
your message.  If you're submitting a patch for approval, you should
put "RFA" in your subject.

"RFC" and "WIP" I *think* both mean that you're just asking for
comments, but you plan to revise the patch before really submitting it
("RFA").

Re: [PATCH] DWARF support for .debug_loc offsets

[Daniel Berlin]

On 11 Jul 2002, Jim Blandy wrote:

> 
> A procedural nit: putting "PATCH" in the subject line means by
> convention that you've committed, or are about to commit, the patch in
> your message.  If you're submitting a patch for approval, you should
> put "RFA" in your subject.

You are aware, that the idea that putting [PATCH] in the line means you 
are committing a patch, is pretty much different than every other project?

Look at GCC, fer instance.
[PATCH] means it's a patch, to be looked at.  

It's very confusing to submit patches to GDB, when it's the only one with 
different procedures.

> 
> "RFC" and "WIP" I *think* both mean that you're just asking for
> comments, but you plan to revise the patch before really submitting it
> ("RFA").
> 
> 

Re: [PATCH] DWARF support for .debug_loc offsets

[Jim Blandy]

Petr Sorfa <petrs@caldera.com> writes:
> This patch provides support for offsets into .debug_loc.
> 
> The patch does not include .debug_loc support in read_tag_string_type()
> as the DW_AT_string_length attribute is currently being misused by GCC
> (it uses it to hold the length, rather than the location to the length)
> and GDB supports the incorrect form.
> 
> There is a second part of this patch which is dependent on FORTRAN95
> support of modules and will be released later.

I'm confused.  If (say) a DW_AT_frame_base attribute's value uses
DW_FORM_data4 or DW_FORM_data8, then that data is the offset in the
.debug_loc section of a location list describing how to find the
object at various points in the code.  But your code seems to assume
that the data in the .debug_loc section is simply the address of the
object.

Having location list support would be great, but if we can get
Daniel's LOC_COMPUTED patch committed, adding location list support
will be very simple.

Re: [PATCH] DWARF support for .debug_loc offsets

[Jim Blandy]

Daniel Berlin <dberlin@dberlin.org> writes:
> On 11 Jul 2002, Jim Blandy wrote:
> > A procedural nit: putting "PATCH" in the subject line means by
> > convention that you've committed, or are about to commit, the patch in
> > your message.  If you're submitting a patch for approval, you should
> > put "RFA" in your subject.
> 
> You are aware, that the idea that putting [PATCH] in the line means you 
> are committing a patch, is pretty much different than every other
> project?

No, I wasn't aware of that at all.

> Look at GCC, fer instance.
> [PATCH] means it's a patch, to be looked at.  
> 
> It's very confusing to submit patches to GDB, when it's the only one with 
> different procedures.

It seems to me GDB's conventions have been working pretty well, but
maybe that's because we deal with regular contributors.  But if there
are, in fact, established, widely-used conventions, then I think GDB
should use them.

Re: [PATCH] DWARF support for .debug_loc offsets

[Petr Sorfa]

Hi Jim,

Sorry for the [PATCH] debacle will use [RFA]. Comments below.

> Petr Sorfa <petrs@caldera.com> writes:
> > This patch provides support for offsets into .debug_loc.
> >
> > The patch does not include .debug_loc support in read_tag_string_type()
> > as the DW_AT_string_length attribute is currently being misused by GCC
> > (it uses it to hold the length, rather than the location to the length)
> > and GDB supports the incorrect form.
> >
> > There is a second part of this patch which is dependent on FORTRAN95
> > support of modules and will be released later.
> 
> I'm confused.  If (say) a DW_AT_frame_base attribute's value uses
> DW_FORM_data4 or DW_FORM_data8, then that data is the offset in the
> ..debug_loc section of a location list describing how to find the
> object at various points in the code.  But your code seems to assume
> that the data in the .debug_loc section is simply the address of the
> object.
> 
> Having location list support would be great, but if we can get
> Daniel's LOC_COMPUTED patch committed, adding location list support
> will be very simple.
Oops, you are completely correct. Let me remove the DW_FORM_data4/8
stuff for DW_AT_frame_base and resubmit the patch for RFA. Is this OK?

Petr

Re: [PATCH] DWARF support for .debug_loc offsets

[Jim Blandy]

Petr Sorfa <petrs@caldera.com> writes:
> Sorry for the [PATCH] debacle will use [RFA]. Comments below.

(Well, it's hardly a debacle; more like a minor bureaucratic point.
But it's a useful convention, so I try to spread the news when the
need arises.)

> > Petr Sorfa <petrs@caldera.com> writes:
> > > This patch provides support for offsets into .debug_loc.
> > >
> > > The patch does not include .debug_loc support in read_tag_string_type()
> > > as the DW_AT_string_length attribute is currently being misused by GCC
> > > (it uses it to hold the length, rather than the location to the length)
> > > and GDB supports the incorrect form.
> > >
> > > There is a second part of this patch which is dependent on FORTRAN95
> > > support of modules and will be released later.
> > 
> > I'm confused.  If (say) a DW_AT_frame_base attribute's value uses
> > DW_FORM_data4 or DW_FORM_data8, then that data is the offset in the
> > ..debug_loc section of a location list describing how to find the
> > object at various points in the code.  But your code seems to assume
> > that the data in the .debug_loc section is simply the address of the
> > object.
> > 
> > Having location list support would be great, but if we can get
> > Daniel's LOC_COMPUTED patch committed, adding location list support
> > will be very simple.
> Oops, you are completely correct. Let me remove the DW_FORM_data4/8
> stuff for DW_AT_frame_base and resubmit the patch for RFA. Is this OK?

The only thing that'll be left is the code that checks the form, and
complains if it's not DW_FORM_block, right?  Yes, that'll be fine.

Re: [PATCH] DWARF support for .debug_loc offsets

[Petr Sorfa]

Hi,

> (Well, it's hardly a debacle; more like a minor bureaucratic point.
> But it's a useful convention, so I try to spread the news when the
> need arises.)
Heh.

> The only thing that'll be left is the code that checks the form, and
> complains if it's not DW_FORM_block, right?  Yes, that'll be fine.
Yes.

Petr

Re: [PATCH] DWARF support for .debug_loc offsets

[Andrew Cagney]

> Daniel Berlin <dberlin@dberlin.org> writes:
> 
>> On 11 Jul 2002, Jim Blandy wrote:
> 
>> > A procedural nit: putting "PATCH" in the subject line means by
>> > convention that you've committed, or are about to commit, the patch in
>> > your message.  If you're submitting a patch for approval, you should
>> > put "RFA" in your subject.
> 
>> 
>> You are aware, that the idea that putting [PATCH] in the line means you 
>> are committing a patch, is pretty much different than every other
>> project?
> 
> 
> No, I wasn't aware of that at all.
> 
> 
>> Look at GCC, fer instance.
>> [PATCH] means it's a patch, to be looked at.  
>> 
>> It's very confusing to submit patches to GDB, when it's the only one with 
>> different procedures.
> 
> 
> It seems to me GDB's conventions have been working pretty well, but
> maybe that's because we deal with regular contributors.  But if there
> are, in fact, established, widely-used conventions, then I think GDB
> should use them.

It gets regular comments and does confuse people.  There have been 
several attempts but no one has come up with a convention that sticks.

Andrew