RE: [PATCH 4/6] Dwarf: Fortran, support DW_TAG_entry_point.

Wiederhake, Tim
2017-08-08T14:36:04Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3585 bytes --]

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
\x16º&Öéj×!zÊÞ¶êç×<ßYb²Ö«r\x18\x1dn–­r\x17¬