From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id LonKFlel82KsUSQAWB0awg (envelope-from ) for ; Wed, 10 Aug 2022 08:32:23 -0400 Received: by simark.ca (Postfix, from userid 112) id 498171E5EA; Wed, 10 Aug 2022 08:32:23 -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=MPGxYBF0; 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=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,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 C62571E21F for ; Wed, 10 Aug 2022 08:32:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D332E3857343 for ; Wed, 10 Aug 2022 12:32:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D332E3857343 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1660134741; bh=kaKrzXJU9on1aK71u/joU6Wftsi6TPaHhnwfmHu+bpU=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=MPGxYBF0J6WsFApJysPel+Xkn2VuDGMhE1XB6vwt+JO5c/JSOw8QydDEez/kNwEhQ L8k4JMfTizyEXdwbEvp2YwZEmEEzGUYTnhg9oB6tTFeyUKu9IomrM8R9/ABQYV9Hdr jySEj5tY+jPFZ3ouDO3bH+TRDgGmAcmMkiIWUyEE= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CAC953858D1E for ; Wed, 10 Aug 2022 12:32:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CAC953858D1E Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-210-9Cq8ZdlVOaGSxnCiI1lPIg-1; Wed, 10 Aug 2022 08:31:59 -0400 X-MC-Unique: 9Cq8ZdlVOaGSxnCiI1lPIg-1 Received: by mail-ed1-f72.google.com with SMTP id c14-20020a05640227ce00b0043e5df12e2cso9143378ede.15 for ; Wed, 10 Aug 2022 05:31:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=kaKrzXJU9on1aK71u/joU6Wftsi6TPaHhnwfmHu+bpU=; b=CZ4j5qCRG6PdmbAmD1bfejjv8hDvYADO5EdQIVkJAU2Zno9WnxyZkX1sE88nvtI791 paEnlgCyOVUn/T0YR903McfcNB7qeNrJa1W0VvFQsY3pRq5XYcMaGJDDEk4L3j8Nh6WA C2p8+ZctKxbE754sS1rq3bh0v5cr8xcYuVWqsKnddwSBXQ/3ZoFwSZYsr6teO+BZ9iq7 pqzNhH9PPUho9SwU3L8WACcf59X0e1tTFQWNnXfplWrIka6nXwafSOxPhDAwhN9AaFjj z3x7recGit4shvF5nTWgckvpeIUYtgF93G7JG4786NjbekBsat6ikaI3OZuOxQaGptyo Zf2w== X-Gm-Message-State: ACgBeo1M7rNFsd5HJUqcG7hbmEe6j57EgRRzqcYbfdLgt5JTnQ8F2JXj vz71HtDpmy8Nrvq+wxgAuKxtBx6HqgC/bldGUGmf8KZzFvPONmxLIb9QvWTJq2xqjRwSnMfvkof VW24H5EdWI28wGrjFruPiww== X-Received: by 2002:a05:6402:3595:b0:43d:710a:3f3f with SMTP id y21-20020a056402359500b0043d710a3f3fmr26150879edc.375.1660134718130; Wed, 10 Aug 2022 05:31:58 -0700 (PDT) X-Google-Smtp-Source: AA6agR6saHn0TATsiglqYn3MgSgXCzXGierH7HgZ5r14e+fcBQLg887ImcVuuFFpliI3povsNIdFSA== X-Received: by 2002:a05:6402:3595:b0:43d:710a:3f3f with SMTP id y21-20020a056402359500b0043d710a3f3fmr26150870edc.375.1660134717917; Wed, 10 Aug 2022 05:31:57 -0700 (PDT) Received: from [10.43.2.144] (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id c4-20020a056402158400b0043c7efb8badsm7547034edv.61.2022.08.10.05.31.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Aug 2022 05:31:57 -0700 (PDT) Message-ID: <3d9918c1-52f6-5d0e-c57f-5cf27b2e8cc0@redhat.com> Date: Wed, 10 Aug 2022 14:31:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH v2 1/2] gdb, testsuite: adapt function_range expected name To: Nils-Christian Kempke , gdb-patches@sourceware.org References: <20220804130351.3898972-2-nils-christian.kempke@intel.com> In-Reply-To: <20220804130351.3898972-2-nils-christian.kempke@intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed 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: Bruno Larsen via Gdb-patches Reply-To: Bruno Larsen Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 04/08/2022 15:03, Nils-Christian Kempke wrote: > 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. Hi Nils, thank you for working on this! I found this explanation a bit confusing, maybe you could condense it to something like 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 it 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 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. I also think the explanation here could be improved a bit. Maybe something like: # For C++, GDB appends arguments to the names of functions if they don't have # a linkage name. For example, asking gdb to disassemble 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. The code itself LGTM, however I can't approve patches for pushing. -- Cheers, Bruno > + 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 {