PR37132 – RFC patch for generation of DWARF symbol for Fortran's namelists (DW_TAG_namelist)

Tobias Burnus burnus@net-b.de
Sun Nov 24 10:13:00 GMT 2013


Hi all,

attached is an updated version of the patch.

Change:

Tobias Burnus wrote:
> But for "USE mod_name, only: nml", one is supposed to generate a 
> DW_TAG_imported_declaration. And there I am stuck. For normal 
> variables, the DW_TAG_imported_declaration refers to a DW_TAG_variable 
> die. Analogously, for a namelist one would have to refer to a 
> DW_TAG_namelist die. But such DW_TAG_namelist comes with a 
> DW_TAG_namelist_item list. And for the latter, one needs to have the 
> die of all variables in the namelist. But with use-only the symbols 
> aren't use associate and no decl or die exists. (Failing call tree 
> with the patch: gfc_trans_use_stmts -> 
> dwarf2out_imported_module_or_decl_1 -> force_decl_die.)

With the attached patch, one now generates DW_TAG_namelist with no 
DW_TAG_namelist_item and sets DW_AT_declaration.

Thus, for (first file)

   module mm
     integer :: ii
     real :: rr
     namelist /nml/ ii, rr
   end module mm


and (second file):

   subroutine test
     use mm, only: nml
     write(*,nml)
   end subroutine test


One now generates (first file):

  <1><1e>: Abbrev Number: 2 (DW_TAG_module)
     <1f>   DW_AT_name        : mm
     <22>   DW_AT_decl_file   : 1
     <23>   DW_AT_decl_line   : 1
     <24>   DW_AT_sibling     : <0x59>
  <2><28>: Abbrev Number: 3 (DW_TAG_variable)
     <29>   DW_AT_name        : ii
     <2c>   DW_AT_decl_file   : 1
     <2d>   DW_AT_decl_line   : 2
     <2e>   DW_AT_linkage_name: (indirect string, offset: 0x15): __mm_MOD_ii
     <32>   DW_AT_type        : <0x59>
     <36>   DW_AT_external    : 1
     <36>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
  <2><40>: Abbrev Number: 3 (DW_TAG_variable)
     <41>   DW_AT_name        : rr
     <44>   DW_AT_decl_file   : 1
     <45>   DW_AT_decl_line   : 2
     <46>   DW_AT_linkage_name: (indirect string, offset: 0x9): __mm_MOD_rr
     <4a>   DW_AT_type        : <0x60>
     <4e>   DW_AT_external    : 1
     <4e>   DW_AT_location    : 9 byte block: 3 4 0 0 0 0 0 0 0  (DW_OP_addr: 4)
  <2><58>: Abbrev Number: 0
  <1><59>: Abbrev Number: 4 (DW_TAG_base_type)
     <5a>   DW_AT_byte_size   : 4
     <5b>   DW_AT_encoding    : 5        (signed)
     <5c>   DW_AT_name        : (indirect string, offset: 0x29): integer(kind=4)
  <1><60>: Abbrev Number: 4 (DW_TAG_base_type)
     <61>   DW_AT_byte_size   : 4
     <62>   DW_AT_encoding    : 4        (float)
     <63>   DW_AT_name        : (indirect string, offset: 0x12c): real(kind=4)
  <1><67>: Abbrev Number: 5 (DW_TAG_namelist)
     <68>   DW_AT_name        : nml
  <2><6c>: Abbrev Number: 6 (DW_TAG_namelist_item)
     <6d>   DW_AT_namelist_items: <0x28>
  <2><71>: Abbrev Number: 6 (DW_TAG_namelist_item)
     <72>   DW_AT_namelist_items: <0x40>

Second file:

   <2><4f>: Abbrev Number: 3 (DW_TAG_imported_declaration)
     <50>   DW_AT_decl_file   : 1
     <51>   DW_AT_decl_line   : 2
     <52>   DW_AT_import      : <0x70>   [Abbrev Number: 6 (DW_TAG_namelist)]
  <2><56>: Abbrev Number: 4 (DW_TAG_lexical_block)
     <57>   DW_AT_low_pc      : 0xb
     <5f>   DW_AT_high_pc     : 0xb0
  <2><67>: Abbrev Number: 0
  <1><68>: Abbrev Number: 5 (DW_TAG_module)
     <69>   DW_AT_name        : mm
     <6c>   DW_AT_declaration : 1
     <6c>   DW_AT_sibling     : <0x76>
  <2><70>: Abbrev Number: 6 (DW_TAG_namelist)
     <71>   DW_AT_name        : nml
     <75>   DW_AT_declaration : 1
  <2><75>: Abbrev Number: 0
   


Does the dumps look okay? For the first file, DW_TAG_namelist doesn't 
come directly after DW_TAG_module but after its sibling 0x59; does one 
still see that "nml" belongs to that module? (On dwarf2out level, 
context die should point to the module tag, but I don't understand the 
readelf/eu-readelf output well enough to see whether that's also the 
case for the generated dwarf.)

I assume that the compiler can see from the DWARF of the second file 
that "nml" comes from module "mm" and doesn't search the value 
elsewhere. (It is possible to have multiple namelist with the same name 
in different modules.)


For previous version, I did an all-language bootstrap + regtesting; for 
this one, I only build and tested Fortran. I will do a now a full all 
language bootstrap regtesting. Assuming that it is successful:
OK for the trunk?

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nml-debug3.diff
Type: text/x-patch
Size: 12711 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20131124/21ef0492/attachment.bin>


More information about the Fortran mailing list