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

["Wiederhake, Tim" <tim.wiederhake@intel.com>]

[-- 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¬