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

[Tobias Burnus]

On November 28, 2013, Tobias Burnus wrote:
> A slightly early *ping*
>
> Tobias Burnus wrote:
>> 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
>
>