[llvm-dev] [DebugInfo] Fortran namelist support

[Kumar N, Bhuvanendra via llvm-dev]

[Public]

Thanks a lot for the suggestion. I followed it and just raised the review request (https://reviews.llvm.org/D108553)

regards,
bhuvan

From: Adrian Prantl <aprantl at apple.com>
Sent: Tuesday, July 27, 2021 9:07 PM
To: Kumar N, Bhuvanendra <Bhuvanendra.KumarN at amd.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; George, Jini Susan <JiniSusan.George at amd.com>; Sharma, Alok Kumar <AlokKumar.Sharma at amd.com>; Balasubrmanian, Vignesh <Vignesh.Balasubrmanian at amd.com>
Subject: Re: [llvm-dev] [DebugInfo] Fortran namelist support

[CAUTION: External Email]


On Jul 27, 2021, at 6:58 AM, Kumar N, Bhuvanendra via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

[AMD Official Use Only]

Hello Everyone,

I am planning to implement the LLVM changes for fortran NAMELIST feature from DebugInfo point of view.

gfortran already support namelist from DebugInfo point of view, it emits DW_TAG_namelist and DW_TAG_namelist_item die's as shown below. But gdb does not understand these, hence we enhanced gdb to handle namelist variable/type. Soon upstreaming the gdb code changes.

In order to emit the DW_TAG_namelist and DW_TAG_namelist_item die's in LLVM, following LLVM IR changes are proposed, could you please review and comment if any change is required. Namelist in fortran is basically group of variables or arrays. It can be represented as composite type. Already Metadata is created for each of the namelist items like !20, !22 in the below example, we just need to reference to these while handling DW_TAG_namelist_item. This proposal looks simple and uses the existing composite type with a new tag:DW_TAG_namelist. Please let me know if you have any comments or need more information on these.

NOTE: Currently flang also does not emit any metadata to handle namelist DebugInfo. flang code changes for the same will be taken up after the LLVM support for namelist.

Proposed LLVM IR changes for namelist DebugInfo handling (for the sample fortran program shown below):
. . .
!20 = !DILocalVariable(scope: !15, name: "a", file: !3, line: 6, type: !19)
. . .
!22 = !DILocalVariable(scope: !15, name: "b", file: !3, line: 7, type: !19)
. . .
!24 = !{ !26, !27 }
!25 = !DICompositeType(tag: DW_TAG_namelist, file: !3, name: "nml", elements: !24)
!26 = !DIDerivedType(tag: DW_TAG_namelist_item, item: !20)
!27 = !DIDerivedType(tag: DW_TAG_namelist_item, item: !22)
. . .

The DICompositeType looks reasonable, I'm not sure why the DIDerivedType is necessary. Wouldn't it be simpler to just use an MDList "elements: !{20, !22}"?

-- adrian


Thanks and regards,
Bhuvan

Sample program :

program main
  integer :: a, b
  namelist /nml/ a, b

  a = 10
  b = 20
  Write(*,nml)
end program main

dwarfdump of an gfortran emitted binary :
. . .
0x000000b4:     DW_TAG_variable [10]
                  DW_AT_name [DW_FORM_string]   ("a")
                  DW_AT_decl_file [DW_FORM_data1]       ("/home/bhuvan/work/fortran/test/3180/n2.f90")
                  DW_AT_decl_line [DW_FORM_data1]       (20)
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x006d => {0x0000006d} "integer(kind=4)")
                  DW_AT_declaration [DW_FORM_flag_present]      (true)
                  DW_AT_location [DW_FORM_exprloc]      (DW_OP_fbreg -20)

0x000000c0:     DW_TAG_variable [10]
                  DW_AT_name [DW_FORM_string]   ("b")
                  DW_AT_decl_file [DW_FORM_data1]       ("/home/bhuvan/work/fortran/test/3180/n2.f90")
                  DW_AT_decl_line [DW_FORM_data1]       (20)
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x006d => {0x0000006d} "integer(kind=4)")
                  DW_AT_declaration [DW_FORM_flag_present]      (true)
                  DW_AT_location [DW_FORM_exprloc]      (DW_OP_fbreg -24)
. . .
0x000000dd:     DW_TAG_namelist [12] *
                  DW_AT_name [DW_FORM_string]   ("nml")

0x000000e2:       DW_TAG_namelist_item [9]
                    DW_AT_namelist_item [DW_FORM_ref4]  (cu + 0x00b4 => {0x000000b4})

0x000000e7:       DW_TAG_namelist_item [9]
                    DW_AT_namelist_item [DW_FORM_ref4]  (cu + 0x00c0 => {0x000000c0})

0x000000ec:       NULL

Sample GDB commands output (GDB used here is internal, soon it will be upstreamed) :

(gdb) ptype nml
type = Type nml
    integer(kind=4) :: a
    integer(kind=4) :: b
End Type nml

(gdb) print nml
$1 = ( a = 10, b = 20 )
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7CBhuvanendra.KumarN%40amd.com%7Cf641ed1d6f314ee76fac08d951146098%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637629970228845878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8vTKPtEiICDLX3rvRUhqDCYLrNKkgRZ7roZCyMQXmO4%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210823/dbdd4251/attachment-0001.html>