* RFC: Support DW_TAG_entry_point
@ 2009-03-20 22:15 H.J. Lu
2009-03-21 1:02 ` Tom Tromey
2009-04-22 21:13 ` Tom Tromey
0 siblings, 2 replies; 11+ messages in thread
From: H.J. Lu @ 2009-03-20 22:15 UTC (permalink / raw)
To: GDB
I have a patch to support DW_TAG_entry_point. Should I submit it
with a ChangeLog entry?
H.J.
--- gdb/dwarf2read.c.entry 2008-05-07 10:41:46.000000000 -0700
+++ gdb/dwarf2read.c 2008-05-07 11:26:14.000000000 -0700
@@ -1780,6 +1780,7 @@ scan_partial_symbols (struct partial_die
switch (pdi->tag)
{
case DW_TAG_subprogram:
+ case DW_TAG_entry_point:
if (pdi->has_pc_info)
{
if (pdi->lowpc < *lowpc)
@@ -1829,6 +1830,14 @@ scan_partial_symbols (struct partial_die
break;
}
}
+
+ /* A DW_TAG_subprogram DIE may have DW_TAG_entry_point DIEs
+ as children. */
+ if (pdi->tag == DW_TAG_subprogram
+ && pdi->has_children
+ && pdi->die_child
+ && pdi->die_child->tag == DW_TAG_entry_point)
+ scan_partial_symbols (pdi->die_child, lowpc, highpc, cu);
/* If the die has a sibling, skip to the sibling. */
@@ -1981,6 +1990,29 @@ add_partial_symbol (struct partial_die_i
cu->language, objfile);
}
break;
+ case DW_TAG_entry_point:
+ if (pdi->die_parent->tag == DW_TAG_subprogram)
+ {
+ if (pdi->die_parent->is_external)
+ /*prim_record_minimal_symbol (actual_name, pdi->lowpc + baseaddr,
+ mst_text, objfile); */
+ psym = add_psymbol_to_list (actual_name,
+ strlen (actual_name),
+ VAR_DOMAIN, LOC_BLOCK,
+ &objfile->global_psymbols,
+ 0, pdi->lowpc + baseaddr,
+ cu->language, objfile);
+ else
+ /*prim_record_minimal_symbol (actual_name, pdi->lowpc + baseaddr,
+ mst_file_text, objfile); */
+ psym = add_psymbol_to_list (actual_name,
+ strlen (actual_name),
+ VAR_DOMAIN, LOC_BLOCK,
+ &objfile->static_psymbols,
+ 0, pdi->lowpc + baseaddr,
+ cu->language, objfile);
+ }
+ break;
case DW_TAG_variable:
if (pdi->is_external)
{
@@ -2713,6 +2745,7 @@ process_die (struct die_info *die, struc
read_file_scope (die, cu);
break;
case DW_TAG_subprogram:
+ case DW_TAG_entry_point:
read_func_scope (die, cu);
break;
case DW_TAG_inlined_subroutine:
@@ -3276,6 +3309,27 @@ dwarf2_get_pc_bounds (struct die_info *d
/* Found discontinuous range of addresses. */
ret = -1;
}
+ else if (die->tag == DW_TAG_entry_point)
+ {
+ /* DW_TAG_entry_point DIE only has DW_AT_low_pc. We get
+ HIGH from its parent. */
+ attr = dwarf2_attr (die, DW_AT_low_pc, cu);
+ if (attr)
+ {
+ low = DW_ADDR (attr);
+ if (die->parent->tag == DW_TAG_subprogram)
+ {
+ CORE_ADDR parent_low = 0;
+ CORE_ADDR parent_high = 0;
+ if (dwarf2_get_pc_bounds (die->parent, &parent_low,
+ &parent_high, cu))
+ {
+ high = parent_high;
+ ret = 1;
+ }
+ }
+ }
+ }
}
if (high < low)
@@ -3323,6 +3377,7 @@ get_scope_pc_bounds (struct die_info *di
{
switch (child->tag) {
case DW_TAG_subprogram:
+ case DW_TAG_entry_point:
if (dwarf2_get_pc_bounds (child, ¤t_low, ¤t_high, cu))
{
best_low = min (best_low, current_low);
@@ -5581,6 +5636,7 @@ load_partial_dies (bfd *abfd, gdb_byte *
&& !is_type_tag_for_partial (abbrev->tag)
&& abbrev->tag != DW_TAG_enumerator
&& abbrev->tag != DW_TAG_subprogram
+ && abbrev->tag != DW_TAG_entry_point
&& abbrev->tag != DW_TAG_variable
&& abbrev->tag != DW_TAG_namespace
&& abbrev->tag != DW_TAG_member)
@@ -5688,6 +5744,7 @@ load_partial_dies (bfd *abfd, gdb_byte *
if (load_all
|| abbrev->tag == DW_TAG_subprogram
+ || abbrev->tag == DW_TAG_entry_point
|| abbrev->tag == DW_TAG_variable
|| abbrev->tag == DW_TAG_namespace
|| part_die->is_declaration)
@@ -5713,6 +5770,7 @@ load_partial_dies (bfd *abfd, gdb_byte *
|| (cu->language != language_c
&& (last_die->tag == DW_TAG_class_type
|| last_die->tag == DW_TAG_interface_type
+ || last_die->tag == DW_TAG_subprogram
|| last_die->tag == DW_TAG_structure_type
|| last_die->tag == DW_TAG_union_type))))
{
@@ -6028,6 +6086,16 @@ fixup_partial_die (struct partial_die_in
|| part_die->tag == DW_TAG_class_type
|| part_die->tag == DW_TAG_union_type)
guess_structure_name (part_die, cu);
+
+ if (part_die->tag == DW_TAG_entry_point)
+ {
+ if (part_die->die_parent->tag == DW_TAG_subprogram)
+ {
+ part_die->highpc = part_die->die_parent->highpc;
+ if (part_die->lowpc < part_die->highpc)
+ part_die->has_pc_info = 1;
+ }
+ }
}
/* Read the die from the .debug_info section buffer. Set DIEP to
@@ -7437,6 +7505,19 @@ new_symbol (struct die_info *die, struct
add_symbol_to_list (sym, cu->list_in_scope);
}
break;
+ case DW_TAG_entry_point:
+ if (die->parent->tag == DW_TAG_subprogram)
+ {
+ /* SYMBOL_BLOCK_VALUE (sym) will be filled in later by
+ finish_block. */
+ SYMBOL_CLASS (sym) = LOC_BLOCK;
+ attr2 = dwarf2_attr (die->parent, DW_AT_external, cu);
+ if (attr2 && (DW_UNSND (attr2) != 0))
+ add_symbol_to_list (sym, &global_symbols);
+ else
+ add_symbol_to_list (sym, cu->list_in_scope);
+ }
+ break;
case DW_TAG_variable:
/* Compilation with minimal debug info may result in variables
with missing type entries. Change the misleading `void' type
@@ -7839,6 +7920,7 @@ read_type_die (struct die_info *die, str
break;
case DW_TAG_subprogram:
case DW_TAG_subroutine_type:
+ case DW_TAG_entry_point:
this_type = read_subroutine_type (die, cu);
break;
case DW_TAG_array_type:
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: RFC: Support DW_TAG_entry_point
2009-03-20 22:15 RFC: Support DW_TAG_entry_point H.J. Lu
@ 2009-03-21 1:02 ` Tom Tromey
2009-03-21 16:25 ` H.J. Lu
2009-04-22 21:13 ` Tom Tromey
1 sibling, 1 reply; 11+ messages in thread
From: Tom Tromey @ 2009-03-21 1:02 UTC (permalink / raw)
To: H.J. Lu; +Cc: GDB
>>>>> "H" == H J Lu <hongjiu.lu@intel.com> writes:
HJ> I have a patch to support DW_TAG_entry_point. Should I submit it
HJ> with a ChangeLog entry?
Yes. A rationale for the patch would also be helpful, at least to me.
Tom
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Support DW_TAG_entry_point
2009-03-21 1:02 ` Tom Tromey
@ 2009-03-21 16:25 ` H.J. Lu
2009-03-23 18:26 ` Tom Tromey
0 siblings, 1 reply; 11+ messages in thread
From: H.J. Lu @ 2009-03-21 16:25 UTC (permalink / raw)
To: tromey; +Cc: GDB
On Fri, Mar 20, 2009 at 5:50 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "H" == H J Lu <hongjiu.lu@intel.com> writes:
>
> HJ> I have a patch to support DW_TAG_entry_point. Should I submit it
> HJ> with a ChangeLog entry?
>
> Yes. A rationale for the patch would also be helpful, at least to me.
>
DW_TAG_entry_point may be used by Fortran compiler. But gcc
doesn't use it. I guess one reason is gdb doesn't support it. Is
this good enough?
--
H.J.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Support DW_TAG_entry_point
2009-03-21 16:25 ` H.J. Lu
@ 2009-03-23 18:26 ` Tom Tromey
2009-03-23 19:09 ` H.J. Lu
0 siblings, 1 reply; 11+ messages in thread
From: Tom Tromey @ 2009-03-23 18:26 UTC (permalink / raw)
To: H.J. Lu; +Cc: GDB
>>>>> "H.J." == H J Lu <hjl.tools@gmail.com> writes:
Tom> Yes. A rationale for the patch would also be helpful, at least to me.
H.J.> DW_TAG_entry_point may be used by Fortran compiler. But gcc
H.J.> doesn't use it. I guess one reason is gdb doesn't support it. Is
H.J.> this good enough?
Yeah. You also need that ChangeLog entry though...
Tom
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Support DW_TAG_entry_point
2009-03-23 18:26 ` Tom Tromey
@ 2009-03-23 19:09 ` H.J. Lu
0 siblings, 0 replies; 11+ messages in thread
From: H.J. Lu @ 2009-03-23 19:09 UTC (permalink / raw)
To: tromey; +Cc: GDB
On Mon, Mar 23, 2009 at 11:14 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "H.J." == H J Lu <hjl.tools@gmail.com> writes:
>
> Tom> Yes. A rationale for the patch would also be helpful, at least to me.
>
> H.J.> DW_TAG_entry_point may be used by Fortran compiler. But gcc
> H.J.> doesn't use it. I guess one reason is gdb doesn't support it. Is
> H.J.> this good enough?
>
> Yeah. You also need that ChangeLog entry though...
Here is ChangeLog entry. OK to install?
Thanks.
H.J.
---
2009-03-23 H.J. Lu <hongjiu.lu@intel.com>
* dwarf2read.c (scan_partial_symbols): Make a recursive call
if a DIE has children. Handle DW_TAG_entry_point.
(load_partial_dies): Don't skip DW_TAG_entry_point. Follow
children of DW_TAG_subprogram if not C.
(add_partial_symbol): Handle DW_TAG_entry_point.
(process_die): Likewise.
(dwarf2_get_pc_bounds): Likewise.
(get_scope_pc_bounds): Likewise.
(fixup_partial_die): Likewise.
(new_symbol): Likewise.
(read_type_die): Likewise.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Support DW_TAG_entry_point
2009-03-20 22:15 RFC: Support DW_TAG_entry_point H.J. Lu
2009-03-21 1:02 ` Tom Tromey
@ 2009-04-22 21:13 ` Tom Tromey
2009-04-23 10:58 ` Joel Brobecker
1 sibling, 1 reply; 11+ messages in thread
From: Tom Tromey @ 2009-04-22 21:13 UTC (permalink / raw)
To: H.J. Lu; +Cc: GDB
>>>>> "HJ" == H J Lu <hongjiu.lu@intel.com> writes:
HJ> I have a patch to support DW_TAG_entry_point.
I don't really understand most of this patch; perhaps someone more
familiar with dwarf2read.c could review it.
However:
HJ> + /* A DW_TAG_subprogram DIE may have DW_TAG_entry_point DIEs
HJ> + as children. */
HJ> + if (pdi->tag == DW_TAG_subprogram
HJ> + && pdi->has_children
HJ> + && pdi->die_child
HJ> + && pdi->die_child->tag == DW_TAG_entry_point)
HJ> + scan_partial_symbols (pdi->die_child, lowpc, highpc, cu);
This looks strange to me. IIUC, there's no requirement that
DW_TAG_entry_point be the first child.
Tom
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Support DW_TAG_entry_point
2009-04-22 21:13 ` Tom Tromey
@ 2009-04-23 10:58 ` Joel Brobecker
2009-04-23 11:10 ` Jan Kratochvil
0 siblings, 1 reply; 11+ messages in thread
From: Joel Brobecker @ 2009-04-23 10:58 UTC (permalink / raw)
To: Tom Tromey; +Cc: H.J. Lu, GDB
> HJ> I have a patch to support DW_TAG_entry_point.
>
> I don't really understand most of this patch; perhaps someone more
> familiar with dwarf2read.c could review it.
I started reviewing it a while ago, but never got to the end of it.
> However:
>
> HJ> + /* A DW_TAG_subprogram DIE may have DW_TAG_entry_point DIEs
> HJ> + as children. */
> HJ> + if (pdi->tag == DW_TAG_subprogram
> HJ> + && pdi->has_children
> HJ> + && pdi->die_child
> HJ> + && pdi->die_child->tag == DW_TAG_entry_point)
> HJ> + scan_partial_symbols (pdi->die_child, lowpc, highpc, cu);
>
> This looks strange to me. IIUC, there's no requirement that
> DW_TAG_entry_point be the first child.
That was my main observation at the time.
--
Joel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Support DW_TAG_entry_point
2009-04-23 10:58 ` Joel Brobecker
@ 2009-04-23 11:10 ` Jan Kratochvil
2009-04-23 23:43 ` Tom Tromey
0 siblings, 1 reply; 11+ messages in thread
From: Jan Kratochvil @ 2009-04-23 11:10 UTC (permalink / raw)
To: Joel Brobecker; +Cc: Tom Tromey, H.J. Lu, GDB
On Thu, 23 Apr 2009 08:10:03 +0200, Joel Brobecker wrote:
> On Wed, 22 Apr 2009 23:13:27 +0200, Tom Tromey wrote:
> > This looks strange to me. IIUC, there's no requirement that
> > DW_TAG_entry_point be the first child.
>
> That was my main observation at the time.
I guess the whole patch tagets just one compiler's (ifort's?) use of
DW_TAG_entry_point. DWARF standard also says neither that DW_TAG_entry_point
should be a child of DW_TAG_subprogram nor that it should not have its own
DW_AT_high_pc. Therefore assuming DW_TAG_entry_point will be the first child
DIE is ensured for the target compiler this patch was made for.
Still this patch is a clear improvement of the current GDB state while having
no regressions. Shouldn't be a more complete support left as a possible next
patch on top of it?
Just my $0.02,
Jan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Support DW_TAG_entry_point
2009-04-23 11:10 ` Jan Kratochvil
@ 2009-04-23 23:43 ` Tom Tromey
2009-04-23 23:49 ` H.J. Lu
0 siblings, 1 reply; 11+ messages in thread
From: Tom Tromey @ 2009-04-23 23:43 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Joel Brobecker, H.J. Lu, GDB
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> I guess the whole patch tagets just one compiler's (ifort's?) use
Jan> of DW_TAG_entry_point. DWARF standard also says neither that
Jan> DW_TAG_entry_point should be a child of DW_TAG_subprogram nor
Jan> that it should not have its own DW_AT_high_pc. Therefore
Jan> assuming DW_TAG_entry_point will be the first child DIE is
Jan> ensured for the target compiler this patch was made for.
Ok, I went and looked through DWARF 3 again to try to understand more.
I think this means that the compiler in question is emitting invalid
DWARF, or at least using its own extension. In that case I suppose I
would be more inclined to allow this, provided that it doesn't impact
the possibility of correctly implementing DW_TAG_entry_point in the
future (maybe the patch already does this too, I really don't know).
Assuming this is an extension, I would like a comment to that effect,
mentioning the compiler. A test case wouldn't hurt, either.
Tom
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Support DW_TAG_entry_point
2009-04-23 23:43 ` Tom Tromey
@ 2009-04-23 23:49 ` H.J. Lu
2009-04-24 0:13 ` Joel Brobecker
0 siblings, 1 reply; 11+ messages in thread
From: H.J. Lu @ 2009-04-23 23:49 UTC (permalink / raw)
To: tromey; +Cc: Jan Kratochvil, Joel Brobecker, GDB
On Thu, Apr 23, 2009 at 4:42 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>
> Jan> I guess the whole patch tagets just one compiler's (ifort's?) use
> Jan> of DW_TAG_entry_point. DWARF standard also says neither that
> Jan> DW_TAG_entry_point should be a child of DW_TAG_subprogram nor
> Jan> that it should not have its own DW_AT_high_pc. Therefore
> Jan> assuming DW_TAG_entry_point will be the first child DIE is
> Jan> ensured for the target compiler this patch was made for.
>
> Ok, I went and looked through DWARF 3 again to try to understand more.
>
> I think this means that the compiler in question is emitting invalid
> DWARF, or at least using its own extension. In that case I suppose I
> would be more inclined to allow this, provided that it doesn't impact
> the possibility of correctly implementing DW_TAG_entry_point in the
> future (maybe the patch already does this too, I really don't know).
I will take a look.
> Assuming this is an extension, I would like a comment to that effect,
> mentioning the compiler. A test case wouldn't hurt, either.
>
I do have a testcase. But you need ifort to use it.
--
H.J.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Support DW_TAG_entry_point
2009-04-23 23:49 ` H.J. Lu
@ 2009-04-24 0:13 ` Joel Brobecker
0 siblings, 0 replies; 11+ messages in thread
From: Joel Brobecker @ 2009-04-24 0:13 UTC (permalink / raw)
To: H.J. Lu; +Cc: tromey, Jan Kratochvil, GDB
> > Assuming this is an extension, I would like a comment to that effect,
> > mentioning the compiler. Â A test case wouldn't hurt, either.
> >
>
> I do have a testcase. But you need ifort to use it.
We have a gdb.dwarf2 section where you can provide hard-coded dwarf2
data. That would be very helpful in making sure that we don't break
GDB with ifort's output later on.
--
Joel
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-04-24 0:13 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-20 22:15 RFC: Support DW_TAG_entry_point H.J. Lu
2009-03-21 1:02 ` Tom Tromey
2009-03-21 16:25 ` H.J. Lu
2009-03-23 18:26 ` Tom Tromey
2009-03-23 19:09 ` H.J. Lu
2009-04-22 21:13 ` Tom Tromey
2009-04-23 10:58 ` Joel Brobecker
2009-04-23 11:10 ` Jan Kratochvil
2009-04-23 23:43 ` Tom Tromey
2009-04-23 23:49 ` H.J. Lu
2009-04-24 0:13 ` Joel Brobecker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox