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 68E22394B00D for ; Mon, 9 May 2022 20:57:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 68E22394B00D Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 249KBw3V000676; Mon, 9 May 2022 20:57:57 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3fy9sa8t46-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 May 2022 20:57:57 +0000 Received: from m0098393.ppops.net (m0098393.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 249Kvub9003269; Mon, 9 May 2022 20:57:56 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3fy9sa8t3u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 May 2022 20:57:56 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 249KvapN013969; Mon, 9 May 2022 20:57:56 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma04dal.us.ibm.com with ESMTP id 3fwgd9vs86-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 May 2022 20:57:56 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 249Kvtkd20578756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 May 2022 20:57:55 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 43D29AC05E; Mon, 9 May 2022 20:57:55 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BF288AC059; Mon, 9 May 2022 20:57:54 +0000 (GMT) Received: from lexx (unknown [9.160.59.210]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 9 May 2022 20:57:54 +0000 (GMT) Message-ID: <37d2a4b6a57b62662f0417f123bda6ba48066554.camel@vnet.ibm.com> Subject: Re: [PATCH V2] PowerPC: fix for gdb.base/eh_return.exp From: will schmidt To: Carl Love , Pedro Alves , Kevin Buettner , gdb-patches@sourceware.org Cc: Rogerio Alves Date: Mon, 09 May 2022 15:57:54 -0500 In-Reply-To: References: <76bea9ad010a71ea5e2c7fd78f818bdb399810a6.camel@us.ibm.com> <20220506110826.5e16c8b6@f35-zws-1> <70a877cc-2f35-3924-6717-9d519c2730c5@palves.net> <099c8f8d8729a0051f83a034d62c18f03c789167.camel@vnet.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-ORIG-GUID: Rv6_QOuuKSOjdHT1fod53dW4piK9FhiE X-Proofpoint-GUID: 3tkA_V_hfdERrCt89vPU2LvSfmp6bs-6 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-09_05,2022-05-09_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 suspectscore=0 mlxscore=0 spamscore=0 adultscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205090105 X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 09 May 2022 20:58:01 -0000 On Mon, 2022-05-09 at 12:17 -0700, Carl Love wrote: > Will, Pedro, Kevin, GDB maintainers: > > Sorry, resend, the first attempt was missing the mailing list. > > I have updated the patch per the comments from Will. The new version > of the patch uses a PowerPC specific gcc option to suppress the > generation of the Traceback Table information. The Traceback > information is contained in the .long statements following the last > instruction in the function. Now the existing test to locate the last > instruction in the function works without any changes. In this cases the disassembly is presenting the traceback table contents as .long values, but with an (un)lucky combination of bits, it may also represent parts of that table as instructions. Thats all chance on which bits/fields are set. That can show up readily with the "-mtraceback=full" option, probably unlikely with the default trace table contents. (tldr; it won't always be represented as .long 0xfoo...). > > Note, the use of the gcc mtraceback option is not valid on other > architectures. > > I have tested the patch on Power 10 and Intel. > > Please let me know if this patch is acceptable. Thanks for the input > and help with the patch. > > Carl Love > ----------------------------------------------------------------- > > PowerPC: fix for gdb.base/eh_return.exp > > Disable the Traceback Table generation on PowerPC. The Traceback Table Disable ... for this test. > consists of multiple .long statement following the final instruction in The traceback table is being interpreted by the assembler as data and is represented as .long by the disassembler that is looking for instructions, but the table itself is a series of mostly bitfields. I'll suggest rephrasing, something like s/consists ... statements /is defined by the PowerPC ELF ABI and is intended to support debuggers and exception handlers. The Traceback Table is located following the end of the code for every function. > the function. Generation of the .long statements needs to be disabled with > the PowerPC specific gcc compiler option -mtraceback=no so the test will > correctly locate the address of the bclr instruction before the statement > "End of assembler dump." > --- > gdb/testsuite/gdb.base/eh_return.exp | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp > index df55dbc72da..3a49464af63 100644 > --- a/gdb/testsuite/gdb.base/eh_return.exp > +++ b/gdb/testsuite/gdb.base/eh_return.exp > @@ -18,8 +18,30 @@ > > standard_testfile > > +if {[istarget "powerpc*"]} then { > + # PowerPC generates a Traceback Table following each function by default. Consider adding "as defined by the PPC64 ABIs" betwen Table and Following. > + # The .long statements following the function contain the Traceback Table > + # information. For example: > + # Dump of assembler code for function eh2: > + # 0x00000000100009e0 <+0>: lis r2,4098 > + # ... > + # 0x0000000010000b04 <+292>: add r1,r1,r10 > + # 0x0000000010000b08 <+296>: blr > + # 0x0000000010000b0c <+300>: .long 0x0 > + # 0x0000000010000b10 <+304>: .long 0x1000000 > + # 0x0000000010000b14 <+308>: .long 0x1000180 > + # End of assembler dump. > + # > + # Disable the Traceback Table generation, using the PowerPC specific > + # gcc option, so the test gdb_test_multiple "disassemble eh2" will match > + # the blr instruction not the .long statement. > + set compile_flags {debug nopie additional_flags=-mtraceback=no} > +} else { > + set compile_flags {debug nopie} > +} This seems OK to me, assuming this test is exercising a simple scenario, versus representative of function elsewhere in the GDB code base. If there is a deeper issue that the traceback tables are causing elsewhere in the GDB code base, some deeper solution may need to be investigated. > + > if {[prepare_for_testing "failed to prepare" $testfile $srcfile \ > - {debug nopie}]} { > + $compile_flags]} { > return -1 > } >