From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QO1qNeXD62KWlSAAWB0awg (envelope-from ) for ; Thu, 04 Aug 2022 09:04:37 -0400 Received: by simark.ca (Postfix, from userid 112) id D73D31EA05; Thu, 4 Aug 2022 09:04:37 -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=fN0g8VcH; 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=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 507591E9EB for ; Thu, 4 Aug 2022 09:04:37 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0106C385E017 for ; Thu, 4 Aug 2022 13:04:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0106C385E017 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659618277; bh=qmS2MSkIEidiP+C8JYtxOMVw7WH8Nl4AdkETODGwI/4=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=fN0g8VcH1CKjki0mdGo3Rk/1ZywmY+SKRVn0hW0W2jJ3b4Orsx6yHlw+evp0WkHZi 7+litL1qpbgZn8hQOddZnjzwiRbOrc5nCxRets18iAX5WzYEQOwxWDvYDpD1SGkZ82 tKBKVSom7yMWxHNuzeWvv27uWCkYUfgUlI6Z059Y= Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by sourceware.org (Postfix) with ESMTPS id 6115A384D194 for ; Thu, 4 Aug 2022 13:04:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6115A384D194 X-IronPort-AV: E=McAfee;i="6400,9594,10429"; a="289937297" X-IronPort-AV: E=Sophos;i="5.93,215,1654585200"; d="scan'208";a="289937297" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2022 06:03:59 -0700 X-IronPort-AV: E=Sophos;i="5.93,215,1654585200"; d="scan'208";a="579066199" Received: from labpcdell3650-003.iul.intel.com (HELO localhost) ([172.28.49.87]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2022 06:03:57 -0700 To: gdb-patches@sourceware.org Subject: [PATCH v2 1/2] gdb, testsuite: adapt function_range expected name Date: Thu, 4 Aug 2022 15:03:50 +0200 Message-Id: <20220804130351.3898972-2-nils-christian.kempke@intel.com> X-Mailer: git-send-email 2.25.1 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 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 does not only happen for 'main' but also for all other C++ functions. However, other functions often also have a DW_AT_linkage_name which gets printed over the function name in 'disassemble' and similar functions. So, I could only really reproduce the fail of MARCRO_AT_rang with the C++ 'main' function. 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 356451bcaac..2c1c4056346 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. These names + # will (if no linkage name is present, and, e.g., main generally has none) + # make 'dissasemble' print main (and possibly others) as 'main()' or + # 'main(int argc, char **argv)' so we take this into accound here by + # allowing an optinal 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