From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qK5tBFLtBWNsgCwAWB0awg (envelope-from ) for ; Wed, 24 Aug 2022 05:20:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 0DC6C1E4A7; Wed, 24 Aug 2022 05:20:18 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=LItLenSl; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 8EAA81E13B for ; Wed, 24 Aug 2022 05:20:17 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 39DFB385AC0A for ; Wed, 24 Aug 2022 09:20:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 39DFB385AC0A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1661332817; bh=HTW7W+NgYfPgyMExXJodVed0rDVp5pfQU12JYCopHVI=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=LItLenSl0ngjCwyNheGZGoxOovnMY4VGaKDMsUiVM6DbIM+MR7DFR679zrpCbNNay ISa043/MRMIUyBm6eS3UMI6NEVMBCanh58O+UZHQvO/vQtP1dJjjbYOKQNSei75qz3 Ov8N7K6mHafOlS5ADZKtSAXwA3U4nInpZAwl3Jx8= 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 To: gdb-patches@sourceware.org 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-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: , From: Nils-Christian Kempke via Gdb-patches Reply-To: Nils-Christian Kempke Cc: tom@tromey.com Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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