From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 27F183857366 for ; Wed, 2 Nov 2022 15:36:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 27F183857366 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=us.ibm.com Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2A2F0hGb012886 for ; Wed, 2 Nov 2022 15:36:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding : subject; s=pp1; bh=diaESUuraVAqCDGzluAXPB6vlvaJcaCgPj/txl1wT8Q=; b=LUGByFxgqUW5GFi3cyv0SGeMy8b2kk0I46LgXCwtIpY6+HIThQvXaKp6BAvkK4s9FlBJ /NRkj14oK2zi2qrVHqUBR+x/eOjKWzImxHVUU3UaMGvmtmnQ9rVO5x//LvGT23RcfkhL L4tLT63+PLFQRjj6NNRvfBUCzpfv6slIS/Gmw4M9xWpNUUBRApxPQN0nWrPw+iwEdOGS NQFzCa4jSiIBB7THyjkVSMrgXYcPeo7VEKfKI+Zb2cPdP6u7FSbE2MuRBsGJCqu0bvKe crdy4CCz45b7nhrpn3YqYI1ws5MM8cVFo6iDOWbXokwkYFv0nnc86Q0WZrgiLm0O+qU3 dw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3kkmqfxbtr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 02 Nov 2022 15:36:55 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2A2F0u7E015134 for ; Wed, 2 Nov 2022 15:36:55 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3kkmqfxbt1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Nov 2022 15:36:55 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2A2Fajtq016978; Wed, 2 Nov 2022 15:36:54 GMT Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by ppma03dal.us.ibm.com with ESMTP id 3kgutajd05-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Nov 2022 15:36:54 +0000 Received: from smtpav04.dal12v.mail.ibm.com ([9.208.128.131]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2A2FaokK55312776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Nov 2022 15:36:50 GMT Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5F7E15805A; Wed, 2 Nov 2022 15:36:52 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E0B5958052; Wed, 2 Nov 2022 15:36:51 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.10.231]) by smtpav04.dal12v.mail.ibm.com (Postfix) with ESMTP; Wed, 2 Nov 2022 15:36:51 +0000 (GMT) Message-ID: From: Carl Love To: Bruno Larsen , cel@us.ibm.com Cc: "gdb-patches@sourceware.org" , Ulrich Weigand , Will Schmidt Date: Wed, 02 Nov 2022 08:36:51 -0700 In-Reply-To: References: <711495ea-57f4-276d-db50-067b29c14de6@redhat.com> <9cbed9664acd4483eb8ec5a5d1b30a4f44f56ecf.camel@us.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 45ZAmbAsqHwUWc2a49rh-MIHl3eKxN1c X-Proofpoint-ORIG-GUID: YrJWaZVSkqLxQ5401-1By5F2MpfPKkDs Subject: RE: Question: [PATCH] Change calculation of frame_id by amd64 epilogue unwinder X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-02_12,2022-11-02_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0 clxscore=1015 bulkscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 mlxlogscore=847 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211020097 X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Bruno: > > The idea of the patch looks fine, I just have a few style nits > inlined. > > > --- > > .../gdb.base/unwind-on-each-insn.exp | 25 > > +++++++++++++++++-- > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > diff --git a/gdb/testsuite/gdb.base/unwind-on-each-insn.exp > > b/gdb/testsuite/gdb.base/unwind-on-each-insn.exp > > index 3b48805cff8..c908a4b838e 100644 > > --- a/gdb/testsuite/gdb.base/unwind-on-each-insn.exp > > +++ b/gdb/testsuite/gdb.base/unwind-on-each-insn.exp > > @@ -41,7 +41,6 @@ if ![runto_main] then { > > proc get_sp_and_fba { testname } { > > with_test_prefix "get \$sp and frame base $testname" { > > set sp [get_hexadecimal_valueof "\$sp" "*UNKNOWN*"] > > - > > set fba "" > > gdb_test_multiple "info frame" "" { > > -re -wrap ".*Stack level ${::decimal}, frame at > > ($::hex):.*" { > > @@ -75,6 +74,23 @@ gdb_continue_to_breakpoint "enter foo" > > > > # Figure out the range of addresses covered by this function. > > set last_addr_in_foo "" > > + > > +# The disassembly of foo on PowerPC looks like: > > +# Dump of assembler code for function foo: > > +# => 0x00000000100006dc <+0>: std r31,-8(r1) > > +# 0x00000000100006e0 <+4>: stdu r1,-48(r1) > > +# 0x00000000100006e4 <+8>: mr r31,r1 > > +# 0x00000000100006e8 <+12>: nop > > +# 0x00000000100006ec <+16>: addi r1,r31,48 > > +# 0x00000000100006f0 <+20>: ld r31,-8(r1) > > +# 0x00000000100006f4 <+24>: blr > > +# 0x00000000100006f8 <+28>: .long 0x0 > > +# 0x00000000100006fc <+32>: .long 0x0 > > +# 0x0000000010000700 <+36>: .long 0x1000180 > > +# End of assembler dump. > > +# > > +# The last instruction in function foo is blr. Ignore the .long > > +# entries following the blr instruction. > > gdb_test_multiple "disassemble foo" "" { > > -re "^disassemble foo\r\n" { > > exp_continue > > @@ -84,7 +100,11 @@ gdb_test_multiple "disassemble foo" "" { > > exp_continue > > } > > > > - -re "^...($hex) \[^\r\n\]+\r\n" { > > + -re "^...($hex) \[<>+0-9:\s\t\]*\.long\[\s\t\]*\[^\r\n\]*\r\n" > > { > > I wonder if this pattern is unnecessarily strict. Correct me if I'm > wrong, but I think that no architecture has an instruction that > starts > with a . so this pattern could probably be simplified to > > ^...($hex) \[<>+0-9:\s\t\]*\.[^\r\n\]*\r\n > > And no other architectures would have a similar problem in the > future. > > I'm not very knowledgeable on assembly so you may know better in this > area. I do not know of any architectures that have a dot at the beginning of an instruction name. So yes the pattern could be changed as suggested. That will require changing the above comment as well to make it clear we are skipping any "instruction" that starts with a dot, such as .long. > > > + exp_continue > > + } > > + > > + -re "^...($hex)\[^\r\n\]+\r\n" { > You removed a space here, which makes no difference in the pattern > and > makes the diff more confusing My bad, that was not intentional. I was too focused on the above change and didn't notice the accidental dings to the code. Sorry. > > set last_addr_in_foo $expect_out(1,string) > > exp_continue > > } > > @@ -137,6 +157,7 @@ for { set i_count 1 } { true } { incr i_count } > > { > > gdb_test "frame 0" ".*" > > > > set pc [get_hexadecimal_valueof "\$pc" "*UNKNOWN*"] > > + > Unnecessary new line here. Ditto, unintentional change I will undo the unintentional changes and update the needed pattern/comment and post the patch for review. Thanks for the help. Carl