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

[Yao Qi <qiyaoltc at gmail dot com>]

"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?

>> > +    }
>> > +
>> >    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.

-- 
Yao (齐尧)