This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

*ping* Re: PR37132 â RFC patch for generation of DWARF symbol for Fortran's namelists (DW_TAG_namelist)

A slightly early *ping*

Tobias Burnus wrote:
attached is an updated version of the patch.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]