From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D36643858C60 for ; Fri, 21 Jan 2022 16:49:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D36643858C60 Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-495-UhfH-YKwMXCz_wzwAvBcVw-1; Fri, 21 Jan 2022 11:49:38 -0500 X-MC-Unique: UhfH-YKwMXCz_wzwAvBcVw-1 Received: by mail-wm1-f72.google.com with SMTP id l16-20020a1c7910000000b0034e4206ecb7so2473841wme.7 for ; Fri, 21 Jan 2022 08:49:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=e6hr3ydt2Z60SrX5edn5OMQPG/DEwGeqyje9Oxx0v3E=; b=LlpCXjD+ElS4aU35vQnAuxMrlXUzSh4lCdQRjeDSl6mREUmGrOS+ExZae0elVVzPKG tOMGu9DFwXhcQl1R2zkeYWjZjuBnVTwe+ANnNCW3qTeJWeY/IGc80a63jJXYycQRkYaX wO1ZFmZuJTBvkdI9KDxuAnvr3mV1H5MSjdGGz5ClH/hr+BZNJBoIlBGirdlvz+3pjj0Q uLICDZZkaNxLthSQW5AXAzgEsm47OnSOK/Zv0xLdcySpkqXBGmPbo6yu+GJdQZZqmi9y 1AfoiHmlMBCvWU6WNjScTsQHXugH3FYtDFOE/mXAYYtCQ8LrvqjVC3a1f87X16figeQQ 8kRg== X-Gm-Message-State: AOAM531447g6T0+iK+EbDKDcYkbT1A05ImZrPMbsTT5w40bsFnr0b4Gu HeZiYTVwFBiCCmz0RdJ45ehe9dv+X3dVPonCA56qpX+RSipqANaQBwArxak5qNpGw92UGE3pA8f vm6TSIGGY33XQ1vT+8N8xGA== X-Received: by 2002:a05:600c:1e19:: with SMTP id ay25mr1439660wmb.131.1642783777008; Fri, 21 Jan 2022 08:49:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJwfMAok2OHteSg8IsBZHj9tQnOASyyJUvw/HvABrFA39aSUxlBvA/WwSISW0dC6MovBDmeuNQ== X-Received: by 2002:a05:600c:1e19:: with SMTP id ay25mr1439648wmb.131.1642783776722; Fri, 21 Jan 2022 08:49:36 -0800 (PST) Received: from localhost (host86-188-49-82.range86-188.btcentralplus.com. [86.188.49.82]) by smtp.gmail.com with ESMTPSA id a9sm6171814wmm.32.2022.01.21.08.49.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jan 2022 08:49:36 -0800 (PST) Date: Fri, 21 Jan 2022 16:49:33 +0000 From: Andrew Burgess To: Nils-Christian Kempke Cc: gdb-patches@sourceware.org, brobecker@adacore.com Subject: Re: [PATCH v2 1/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers Message-ID: <20220121164933.GL622389@redhat.com> References: <20220117113005.3867815-1-nils-christian.kempke@intel.com> <20220117113005.3867815-2-nils-christian.kempke@intel.com> MIME-Version: 1.0 In-Reply-To: <20220117113005.3867815-2-nils-christian.kempke@intel.com> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 16:48:26 up 20 days, 1:42, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2022 16:49:49 -0000 * Nils-Christian Kempke via Gdb-patches [2022-01-17 12:30:05 +0100]: > Info symbol is expected to print the symbol table name of a symbol, since > symbol lookup happens via the minimal symbol table. This name > corresponds to the linkage name in the full symbol table. > > For gfortran (and maybe others) these names currently have the form > XXXX.NUMBER where XXXX is the symbol name and NUMBER a compiler > generated appendix for mangling. > An example taken from the modified nested-funcs-2.exp would be > > ~~~~ > $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \ > increment > 00000000000014ab l F .text 0000000000000095 increment.3883 > 000000000000141c l F .text 000000000000008f increment_program_global.3881 > ~~~~ > > This mangled name gets recognized by the Ada demangler/decoder and decoded as > Ada to XXXX (setting the symbol language to Ada). This leads to output > of XXXX over XXXX.NUMBER for info symbol on gfortran symbols. > > For ifort and ifx the generated linkage names have the form > SCOPEA_SCOPEB_XXXX_ which are not recognized by the Ada decoder (or any > other demangler for that matter) and thus printed as is. > The respective objdump in the above case looks like > > ~~~~ > $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \ > increment > 0000000000403a44 l F .text 0000000000000074 contains_keyword_IP_increment_ > 0000000000403ab8 l F .text 0000000000000070 > contains_keyword_IP_increment_program_global_ > ~~~~ > > In the unmodified testcase this results in 'fails' when ran with the intel > compilers: > > ~~~~ > >> make check RUNTESTFLAGS="gdb.fortran/nested-funcs-2.exp \ > GDBFLAGS='$GDBFLAGS' CC_FOR_TARGET='icpc' F90_FOR_TARGET='ifort'" > > ... > > === gdb Summary === > > \# of expected passes 80 > \# of unexpected failures 14 > ~~~~ > > Note that there is no Fortran mangling standard. We keep the gfortran > behavior as is and modify the test to reflect ifx and ifort mangled > names which fixes above fails. > > Signed-off-by: Nils-Christian Kempke You might want to wait a couple more days in case Joel wants to follow up, but I think this looks good. If Joel doesn't get back to you, then feel free to push this next week. Thanks, Andrew > --- > gdb/testsuite/gdb.fortran/nested-funcs-2.exp | 29 ++++++++++++++++++-- > 1 file changed, 27 insertions(+), 2 deletions(-) > > diff --git a/gdb/testsuite/gdb.fortran/nested-funcs-2.exp b/gdb/testsuite/gdb.fortran/nested-funcs-2.exp > index d04fd0987e..6009cb65c5 100644 > --- a/gdb/testsuite/gdb.fortran/nested-funcs-2.exp > +++ b/gdb/testsuite/gdb.fortran/nested-funcs-2.exp > @@ -50,6 +50,31 @@ proc do_bp_tests {with_src_prefix_p with_nest_prefix_p} { > set nest_prefix "" > } > > + # Normally, info symbol prints the symbol table name for any fortran > + # symbols (since symbol lookup happens via the minimal symbol > + # table). This would correspond to the linkage name in the full symbol > + # table. > + # For gfortran (and maybe others) these names currently have the form > + # XXXX.NUMBER where XXXX is the symbol name and NUMBER a compiler generated > + # appendix for mangling. This mangled name gets recognized by the Ada > + # demangler/decoder and decoded as Ada (setting the symbol language to Ada) > + # to XXXX. This leads to the somewhat unexpected output of XXXX over > + # XXXX.NUMBER for info symbol. > + # For ifort and ifx the generated linkage names have the form > + # SCOPEA_SCOPEB_XXXX_ which is not recognized by the Ada demangler and thus > + # printed as is. > + # Note that there is no Fortran mangling standard. We keep the > + # gfortran behavior as is and extend the test to reflect ifx and ifort > + # mangling. > + proc get_linkage_name_pattern {symbol_name} { > + > + if { [test_compiler_info icc*] || [test_compiler_info intel*]} { > + return "\(?:.*_\)?${symbol_name}_?" > + } else { > + return ${symbol_name} > + } > + } > + > # Test setting up breakpoints and otherwise examining nested > # functions before the program starts. > with_test_prefix "before start" { > @@ -68,7 +93,7 @@ proc do_bp_tests {with_src_prefix_p with_nest_prefix_p} { > # is a failure, just a limitation in current GDB. > if { ${with_nest_prefix_p} } { > gdb_test "info symbol ${nest_prefix}${function}" \ > - "${function} in section .*" > + "[get_linkage_name_pattern ${function}] in section .*" > gdb_test "whatis ${nest_prefix}${function}" \ > "type = ${type}" > gdb_test "ptype ${nest_prefix}${function}" \ > @@ -134,7 +159,7 @@ proc do_bp_tests {with_src_prefix_p with_nest_prefix_p} { > set type [lindex $entry 1] > with_test_prefix $function { > gdb_test "info symbol ${nest_prefix}$function" \ > - "$function in section .*" > + "[get_linkage_name_pattern $function] in section .*" > gdb_test "whatis ${nest_prefix}$function" \ > "type = ${type}" > gdb_test "ptype ${nest_prefix}$function" \ > -- > 2.25.1 > > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 >