This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH 4/6] Dwarf: Fortran, support DW_TAG_entry_point.
- From: "Wiederhake, Tim" <tim dot wiederhake at intel dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 8 Aug 2017 14:35:58 +0000
- Subject: RE: [PATCH 4/6] Dwarf: Fortran, support DW_TAG_entry_point.
- Authentication-results: sourceware.org; auth=none
- Dlp-product: dlpe-windows
- Dlp-reaction: no-action
- Dlp-version: 10.0.102.7
- References: <1500629040-12972-1-git-send-email-tim.wiederhake@intel.com> <1500629040-12972-5-git-send-email-tim.wiederhake@intel.com> <86tw1q2jt3.fsf@gmail.com> <9676A094AF46E14E8265E7A3F4CCE9AF5AC20F28@irsmsx105.ger.corp.intel.com> <86a83b1urh.fsf@gmail.com>
Hi Yao!
> -----Original Message-----
> From: Yao Qi [mailto:qiyaoltc@gmail.com]
> Sent: Monday, August 7, 2017 1:29 PM
> To: Wiederhake, Tim <tim.wiederhake@intel.com>
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH 4/6] Dwarf: Fortran, support DW_TAG_entry_point.
>
> "Wiederhake, Tim" <tim.wiederhake@intel.com> writes:
>
> >> Why return PC_BOUNDS_HIGH_LOW, which means both DW_AT_low_pc and
> >> DW_AT_high_pc are found. However, DW_TAG_entry_point doesn't have
> >> DW_AT_high_pc. The question is why do we call dwarf2_get_pc_bounds for
> >> DW_TAG_entry_point. Is it because we call read_func_scope for
> >> DW_TAG_entry_point?
> >
> > I may be misunderstanding you here. Yes, DW_TAG_entry_point doesn't
> > have DW_AT_high_pc but we know that value implicitly from the
> surrounding
> > subprogram, as explained in the comment above.
> >
>
> Yes, the comments above are clear to me. My question is why do we need
> to know the bounds or scope for DW_TAG_entry_point? Is there anything
> wrong if we don't get bounds or scope for DW_TAG_entry_point?
We need the bounds for disassembly.
> >> > + }
> >> > +
> >> > attr_high = dwarf2_attr (die, DW_AT_high_pc, cu);
> >> > if (attr_high)
> >> > {
> >> > @@ -16029,6 +16103,7 @@ load_partial_dies (const struct
> die_reader_specs
> >> *reader,
> >> > && abbrev->tag != DW_TAG_constant
> >> > && abbrev->tag != DW_TAG_enumerator
> >> > && abbrev->tag != DW_TAG_subprogram
> >> > + && abbrev->tag != DW_TAG_entry_point
> >> > && abbrev->tag != DW_TAG_lexical_block
> >> > && abbrev->tag != DW_TAG_variable
> >> > && abbrev->tag != DW_TAG_namespace
> >> > @@ -16155,6 +16230,7 @@ load_partial_dies (const struct
> die_reader_specs
> >> *reader,
> >> > if (load_all
> >> > || abbrev->tag == DW_TAG_constant
> >> > || abbrev->tag == DW_TAG_subprogram
> >> > + || abbrev->tag == DW_TAG_entry_point
> >>
> >> Could you update the comments above this block?
> >
> >
> > Sorry, which comments specifically?
> > The comment directly above the last block states:
> > DW_AT_abstract_origin refers to functions (and many things under the
> > function DIE [...])"
>
> Ah, the comments I mentioned are,
>
> /* For some DIEs we want to follow their children (if any). For C
> we have no reason to follow the children of structures; for other
> languages we have to, so that we can get at method physnames
> to infer fully qualified class names, for DW_AT_specification,
> and for C++ template arguments. For C++, we also look one level
> inside functions to find template arguments (if the name of the
> function does not already contain the template arguments).
>
> For Ada, we need to scan the children of subprograms and lexical
> blocks as well because Ada allows the definition of nested
> entities that could be interesting for the debugger, such as
> nested subprograms for instance. */
>
> we need add comments for Fortran and entry_point after them.
I extended the comment to mention Fortran, see
https://sourceware.org/ml/gdb-patches/2017-08/msg00108.html
Regards,
Tim
>
> --
> Yao (齐尧)
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928