From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by sourceware.org (Postfix) with ESMTPS id B0A863856DDF for ; Wed, 24 Aug 2022 09:19:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B0A863856DDF X-IronPort-AV: E=McAfee;i="6500,9779,10448"; a="355646002" X-IronPort-AV: E=Sophos;i="5.93,260,1654585200"; d="scan'208";a="355646002" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2022 02:19:36 -0700 X-IronPort-AV: E=Sophos;i="5.93,260,1654585200"; d="scan'208";a="937832216" Received: from labpcdell3650-003.iul.intel.com (HELO localhost) ([172.28.49.87]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2022 02:19:35 -0700 From: Nils-Christian Kempke To: gdb-patches@sourceware.org Cc: blarsen@redhat.com, tom@tromey.com, Nils-Christian Kempke Subject: [PATCH v4 1/2] gdb, testsuite: adapt function_range expected name Date: Wed, 24 Aug 2022 11:18:57 +0200 Message-Id: <20220824091858.1255517-2-nils-christian.kempke@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220824091858.1255517-1-nils-christian.kempke@intel.com> References: <20220824091858.1255517-1-nils-christian.kempke@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Wed, 24 Aug 2022 09:19:52 -0000 When writing a dwarf testcase for some C++ code I wanted to use the MACRO_AT_range which in turn uses the function_range proc in dwarf.exp to extract the bounds of 'main'. However, the macro failed as GDB prints the C++ 'main' with its arguments as 'main(int, char**)' or 'main()'. The reason for this is that in read.c::dwarf2_compute_name we call c_type_print_args on C++ functions and append their arguments to the function name. This happens to all C++ functions, but is only visible when the function doesn't have a linkage name. An example might make this more clear. Given the following code >> cat c.cpp int foo (int a, float b) { return 0; } int main (int argc, char **argv) { return 0; } which is legal in both languages, C and C++, and compiling it with e.g. clang or gcc will make the disassemble command look like: >> clang --version clang version 10.0.0-4ubuntu1 ... >> clang -O0 -g ./c.cpp >> gdb -q ./a.out -ex "start" ... (gdb) disassemble main Dump of assembler code for function main(int, char**): 0x0000000000401120 <+0>: push %rbp 0x0000000000401121 <+1>: mov %rsp,%rbp ... 0x0000000000401135 <+21>: ret End of assembler dump. (gdb) disassemble foo Dump of assembler code for function _Z3fooif: 0x0000000000401110 <+0>: push %rbp 0x0000000000401111 <+1>: mov %rsp,%rbp ... 0x000000000040111f <+15>: ret End of assembler dump. Note, that main is emitted with its arguments while for foo the linkage name is being printed, as also visible in its DWARF: >> objdump ./a.out --dwarf=info | grep "foo" -A3 -B3 <2b> DW_AT_low_pc : 0x401110 <33> DW_AT_high_pc : 0x10 <37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp)) <39> DW_AT_linkage_name: (indirect string, offset: 0x39): _Z3fooif <3d> DW_AT_name : (indirect string, offset: 0x42): foo <41> DW_AT_decl_file : 1 <42> DW_AT_decl_line : 1 <43> DW_AT_type : <0x9a> Now, let's rename the C++ file and compile it as C: >> mv c.cpp c.c >> clang -O0 -g ./c.c >> gdb -q ./a.out -ex "start' ... (gdb) disassemble main Dump of assembler code for function main: 0x0000000000401120 <+0>: push %rbp 0x0000000000401121 <+1>: mov %rsp,%rbp ... 0x0000000000401135 <+21>: ret End of assembler dump. (gdb) disassemble foo Dump of assembler code for function foo: 0x0000000000401110 <+0>: push %rbp 0x0000000000401111 <+1>: mov %rsp,%rbp ... 0x000000000040111f <+15>: ret End of assembler dump. Note, for foo we did not get a linkage name emitted in DWARF, so it is printed by its name: >> objdump --dwarf=info ./a.out | grep foo -A3 -B3 <2b> DW_AT_low_pc : 0x401110 <33> DW_AT_high_pc : 0x10 <37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp)) <39> DW_AT_name : (indirect string, offset: 0x37): foo <3d> DW_AT_decl_file : 1 <3e> DW_AT_decl_line : 1 <3f> DW_AT_prototyped : 1 To make the macro and proc work with C++ as well, an optional argument list was added to the regex matching the function name in the disassemble command in function_range. This does not change any used behavior as currently, there exists no C++ test using the proc function_range. Signed-off-by: Nils-Christian Kempke --- gdb/testsuite/lib/dwarf.exp | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/gdb/testsuite/lib/dwarf.exp b/gdb/testsuite/lib/dwarf.exp index 3d833e5cd58..b5474ca6ce4 100644 --- a/gdb/testsuite/lib/dwarf.exp +++ b/gdb/testsuite/lib/dwarf.exp @@ -391,10 +391,14 @@ proc function_range { func src {options {debug}} } { } # Compute the size of the last instruction. - if { $func_length == 0 } then { - set func_pattern "$func" - } else { - set func_pattern "$func\\+$func_length" + # For C++, GDB appends arguments to the names of functions if they don't + # have a linkage name. For example, asking gdb to disassemble a C++ main + # will print the function name as main() or main(int argc, char **argv). + # Take this into account by optionally allowing an argument list after + # the function name. + set func_pattern "$func\(\?\:\\(\.\*\\)\)?" + if { $func_length != 0 } { + set func_pattern "$func_pattern\\+$func_length" } set test "x/2i $func+$func_length" gdb_test_multiple $test $test { -- 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