* [PATCH] DWARF support for .debug_loc offsets
@ 2002-07-11 10:37 Petr Sorfa
2002-07-11 10:49 ` Jim Blandy
2002-07-11 11:03 ` Jim Blandy
0 siblings, 2 replies; 9+ messages in thread
From: Petr Sorfa @ 2002-07-11 10:37 UTC (permalink / raw)
To: gdb-patches
[-- 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)
{
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] DWARF support for .debug_loc offsets
2002-07-11 10:37 [PATCH] DWARF support for .debug_loc offsets Petr Sorfa
@ 2002-07-11 10:49 ` Jim Blandy
2002-07-11 10:57 ` Daniel Berlin
2002-07-11 11:03 ` Jim Blandy
1 sibling, 1 reply; 9+ messages in thread
From: Jim Blandy @ 2002-07-11 10:49 UTC (permalink / raw)
To: Petr Sorfa; +Cc: gdb-patches
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").
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] DWARF support for .debug_loc offsets
2002-07-11 10:49 ` Jim Blandy
@ 2002-07-11 10:57 ` Daniel Berlin
2002-07-11 11:10 ` Jim Blandy
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Berlin @ 2002-07-11 10:57 UTC (permalink / raw)
To: Jim Blandy; +Cc: Petr Sorfa, gdb-patches
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").
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] DWARF support for .debug_loc offsets
2002-07-11 10:57 ` Daniel Berlin
@ 2002-07-11 11:10 ` Jim Blandy
2002-07-11 13:58 ` Andrew Cagney
0 siblings, 1 reply; 9+ messages in thread
From: Jim Blandy @ 2002-07-11 11:10 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Petr Sorfa, gdb-patches
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] DWARF support for .debug_loc offsets
2002-07-11 11:10 ` Jim Blandy
@ 2002-07-11 13:58 ` Andrew Cagney
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Cagney @ 2002-07-11 13:58 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Berlin, Petr Sorfa, gdb-patches
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] DWARF support for .debug_loc offsets
2002-07-11 10:37 [PATCH] DWARF support for .debug_loc offsets Petr Sorfa
2002-07-11 10:49 ` Jim Blandy
@ 2002-07-11 11:03 ` Jim Blandy
2002-07-11 12:20 ` Petr Sorfa
1 sibling, 1 reply; 9+ messages in thread
From: Jim Blandy @ 2002-07-11 11:03 UTC (permalink / raw)
To: Petr Sorfa; +Cc: gdb-patches
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] DWARF support for .debug_loc offsets
2002-07-11 11:03 ` Jim Blandy
@ 2002-07-11 12:20 ` Petr Sorfa
2002-07-11 12:22 ` Jim Blandy
0 siblings, 1 reply; 9+ messages in thread
From: Petr Sorfa @ 2002-07-11 12:20 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] DWARF support for .debug_loc offsets
2002-07-11 12:20 ` Petr Sorfa
@ 2002-07-11 12:22 ` Jim Blandy
2002-07-11 12:44 ` Petr Sorfa
0 siblings, 1 reply; 9+ messages in thread
From: Jim Blandy @ 2002-07-11 12:22 UTC (permalink / raw)
To: Petr Sorfa; +Cc: gdb-patches
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] DWARF support for .debug_loc offsets
2002-07-11 12:22 ` Jim Blandy
@ 2002-07-11 12:44 ` Petr Sorfa
0 siblings, 0 replies; 9+ messages in thread
From: Petr Sorfa @ 2002-07-11 12:44 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-07-11 20:51 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-11 10:37 [PATCH] DWARF support for .debug_loc offsets Petr Sorfa
2002-07-11 10:49 ` Jim Blandy
2002-07-11 10:57 ` Daniel Berlin
2002-07-11 11:10 ` Jim Blandy
2002-07-11 13:58 ` Andrew Cagney
2002-07-11 11:03 ` Jim Blandy
2002-07-11 12:20 ` Petr Sorfa
2002-07-11 12:22 ` Jim Blandy
2002-07-11 12:44 ` Petr Sorfa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox