public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "nils-christian.kempke at intel dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/105272] New: Using entry inside module contained subroutines changes subroutine's scope in DWARF Date: Thu, 14 Apr 2022 06:51:41 +0000 [thread overview] Message-ID: <bug-105272-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105272 Bug ID: 105272 Summary: Using entry inside module contained subroutines changes subroutine's scope in DWARF Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nils-christian.kempke at intel dot com Target Milestone: --- When compiling a subroutine inside a module like $ cat f_no_entry.f90 module a contains subroutine b print *, "b" end subroutine b end module a program prog print *, "hi" end program prog $ gfortran -O0 -g ./f.f90 $ gfortran --version GNU Fortran (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 ... the DWARF emitted shows that the DW_TAG_subprogram for subroutine b is a child of the DW_TAG_module for a. This seems reasonable and puts b into the scope of a: $ objdump --dwarf=info ./a.out ... <1><a0>: Abbrev Number: 8 (DW_TAG_module) <a1> DW_AT_name : a <a3> DW_AT_decl_file : 1 <a4> DW_AT_decl_line : 1 <2><a5>: Abbrev Number: 9 (DW_TAG_subprogram) <a6> DW_AT_external : 1 <a6> DW_AT_name : b <a8> DW_AT_decl_file : 1 <a9> DW_AT_decl_line : 3 <aa> DW_AT_linkage_name: (indirect string, offset: 0x0): __a_MOD_b <ae> DW_AT_low_pc : 0x1179 <b6> DW_AT_high_pc : 0x73 <be> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <c0> DW_AT_GNU_all_tail_call_sites: 1 <2><c0>: Abbrev Number: 0 <1><c1>: Abbrev Number: 0 Changing this example seemingly just a bit by adding an alternative entry point to b via the 'entry' moves the subroutine (and the entry point) out of the module and puts them into the scope of the whole compile unit TAG: $ cat f_entry.f90 module a contains subroutine b entry bbb print *, "b" end subroutine b end module a program prog print *, "hi" end program prog $ gfortran -O0 -g ./f_entry.f90 $ objdump --dwarf=info ./a.out ... <1><a0>: Abbrev Number: 8 (DW_TAG_module) <a1> DW_AT_name : a <a3> DW_AT_decl_file : 1 <a4> DW_AT_decl_line : 1 <a5> DW_AT_sibling : <0xd1> <2><a9>: Abbrev Number: 9 (DW_TAG_subprogram) <aa> DW_AT_name : (indirect string, offset: 0xa): master.0.b <ae> DW_AT_decl_file : 1 <af> DW_AT_decl_line : 7 <b0> DW_AT_low_pc : 0x1199 <b8> DW_AT_high_pc : 0x8c <c0> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <c2> DW_AT_GNU_all_tail_call_sites: 1 <3><c2>: Abbrev Number: 10 (DW_TAG_formal_parameter) <c3> DW_AT_name : (indirect string, offset: 0x57): __entry <c7> DW_AT_type : <0xd8> <cb> DW_AT_artificial : 1 <cb> DW_AT_location : 3 byte block: 91 d8 7b (DW_OP_fbreg: -552) <3><cf>: Abbrev Number: 0 <2><d0>: Abbrev Number: 0 ... <1><d1>: Abbrev Number: 4 (DW_TAG_base_type) <d2> DW_AT_byte_size : 8 <d3> DW_AT_encoding : 5 (signed) <d4> DW_AT_name : (indirect string, offset: 0x27): integer(kind=8) <1><dd>: Abbrev Number: 11 (DW_TAG_subprogram) <de> DW_AT_external : 1 <de> DW_AT_name : bbb <e2> DW_AT_decl_file : 1 <e3> DW_AT_decl_line : 4 <e4> DW_AT_linkage_name: (indirect string, offset: 0x142): __a_MOD_bbb <e8> DW_AT_low_pc : 0x1189 <f0> DW_AT_high_pc : 0x10 <f8> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <fa> DW_AT_GNU_all_tail_call_sites: 1 <1><fa>: Abbrev Number: 11 (DW_TAG_subprogram) <fb> DW_AT_external : 1 <fb> DW_AT_name : b <fd> DW_AT_decl_file : 1 <fe> DW_AT_decl_line : 3 <ff> DW_AT_linkage_name: (indirect string, offset: 0x0): __a_MOD_b <103> DW_AT_low_pc : 0x1179 <10b> DW_AT_high_pc : 0x10 <113> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <115> DW_AT_GNU_all_tail_call_sites: 1 <1><115>: Abbrev Number: 0 This behavior seems odd. I stumbled upon this when trying to access the entry point bbb in gdb via a::bbb (as bbb is in the module's scope) which I could not. There is a likely related issue about gfortran not emitting a DW_TAG_entry_point for entry points https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134.
next reply other threads:[~2022-04-14 6:51 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-14 6:51 nils-christian.kempke at intel dot com [this message] 2022-04-14 8:13 ` [Bug fortran/105272] " rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-105272-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).