Hi Yao! > -----Original Message----- > From: Yao Qi [mailto:qiyaoltc@gmail.com] > Sent: Monday, August 7, 2017 1:29 PM > To: Wiederhake, Tim > Cc: gdb-patches@sourceware.org > Subject: Re: [PATCH 4/6] Dwarf: Fortran, support DW_TAG_entry_point. > > "Wiederhake, Tim" 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 &j!z޶׍