From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jhLXLw6ldWILyQQAWB0awg (envelope-from ) for ; Fri, 06 May 2022 18:45:34 -0400 Received: by simark.ca (Postfix, from userid 112) id B42ED1E21F; Fri, 6 May 2022 18:45:34 -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=PZzm1Wfr; 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 6E6631E01D for ; Fri, 6 May 2022 18:45:33 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D92C1389EC4C for ; Fri, 6 May 2022 22:45:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D92C1389EC4C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1651877132; bh=6VWD3NXEihvpj1xxJsOWIr6azV7rbcljNCPNRqrjXZM=; h=Subject:To:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=PZzm1WfrQx0JTrqgbH8/C8fJoeqXb7+4PKadOyxo8mO+ISZoGloVqb+DpLaMa9T6a CDUddsZIPjgtv1TTq1FPZ4uDD9olNn6mLThqA540ZEIim88ik0vnT3xw6ekYd0Lmrw /ij5cB6Z47f45ivEGnLARhA3CKwUdzmb9DhibDD4= Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id B4551383801F for ; Fri, 6 May 2022 22:45:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B4551383801F Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 246LlqB6015026; Fri, 6 May 2022 22:45:11 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3fwbwh0puf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 May 2022 22:45:10 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 246MfNWm012812; Fri, 6 May 2022 22:45:10 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3fwbwh0pu8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 May 2022 22:45:09 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 246Mg9SY018568; Fri, 6 May 2022 22:45:09 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma02dal.us.ibm.com with ESMTP id 3frvrap3yh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 May 2022 22:45:09 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 246Mj8xk8520154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 6 May 2022 22:45:08 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 456902805A; Fri, 6 May 2022 22:45:08 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D5F6F2805C; Fri, 6 May 2022 22:45:07 +0000 (GMT) Received: from lexx (unknown [9.160.59.210]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 6 May 2022 22:45:07 +0000 (GMT) Message-ID: <099c8f8d8729a0051f83a034d62c18f03c789167.camel@vnet.ibm.com> Subject: Re: [PATCH] PowerPC: fix for gdb.base/eh_return.exp To: Pedro Alves , Kevin Buettner , Carl Love via Gdb-patches Date: Fri, 06 May 2022 17:45:07 -0500 In-Reply-To: <70a877cc-2f35-3924-6717-9d519c2730c5@palves.net> References: <76bea9ad010a71ea5e2c7fd78f818bdb399810a6.camel@us.ibm.com> <20220506110826.5e16c8b6@f35-zws-1> <70a877cc-2f35-3924-6717-9d519c2730c5@palves.net> 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: L0188_aFobVwoju_g9JIaPEuZ1KKrpVY X-Proofpoint-GUID: HdoXf8AvEvbh3Cjm8Po6rStpEX5wJ1JG 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-06_07,2022-05-06_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 impostorscore=0 adultscore=0 suspectscore=0 spamscore=0 lowpriorityscore=0 clxscore=1015 mlxscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205060112 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: will schmidt via Gdb-patches Reply-To: will schmidt Cc: Rogerio Alves Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Fri, 2022-05-06 at 22:16 +0100, Pedro Alves wrote: > On 2022-05-06 19:08, Kevin Buettner via Gdb-patches wrote: > > Hi Carl, > > > > On Thu, 05 May 2022 13:07:29 -0700 > > Carl Love via Gdb-patches wrote: > > > > > PowerPC: fix for gdb.base/eh_return.exp > > > > > > The expect file does a disassembly of function eh2 to get the > > > address of > > > the last instruction of function eh2. The last instruction on > > > PowerPC is > > > followed by three .long entries. This requires a different > > > pattern > > > matching for PowerPC versus other architectures. > > > > > > This patch adds the needed gdb_test_multiple match statement for > > > the > > > PowerPC disassembly code. > > > > > > This patch fixes the one test failure on PowerPC. > > > > > > The patch has been tested on Power 10 and Intel 64. > > > --- > > > gdb/testsuite/gdb.base/eh_return.exp | 16 ++++++++++++++++ > > > 1 file changed, 16 insertions(+) > > > > > > diff --git a/gdb/testsuite/gdb.base/eh_return.exp > > > b/gdb/testsuite/gdb.base/eh_return.exp > > > index df55dbc72da..ce46a3623d9 100644 > > > --- a/gdb/testsuite/gdb.base/eh_return.exp > > > +++ b/gdb/testsuite/gdb.base/eh_return.exp > > > @@ -27,6 +27,22 @@ set address -1 > > > > > > # Get the address of the last insn in function eh2. > > > gdb_test_multiple "disassemble eh2" "" { > > > + -re "($hex)\[^\r\n\]*blr.*" { > > > + # The dissassebmly on Powerpc looks like: > > > + # 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. > > > + # > > > + # Powerpc needs the address for the blr instruction above. > > > + set address $expect_out(1,string) > > > + pass $gdb_test_name > > > + } > > > -re -wrap "($hex)\[^\r\n\]*\r\nEnd of assembler dump." { > > > set address $expect_out(1,string) > > > pass $gdb_test_name > > > -- > > > > I'd prefer to see a solution which doesn't explicitly test for > > PPC's blr > > or any other architecture specific instruction. > > > > It seems to me that the problem results from the .long entries > > following the last executable instruction. My guess is that these > > would be problematic on other architectures too. I think it'd > > be better to write an RE which skips all trailing occurrences of > > $hex\[^\r\n\]*\.long\[^\r\n\]* . > > Do you know why those .long are there in the first place? Kind of > looks like > data in the middle of text? I wonder whether that's a GDB bug or > normal... That appears to be the Traceback Table, which is mentioned in the PowerPC ABIs. (64-bit PowerPC ELF Application Binary Interface Supplement v1.9 section 3.3 ; and 64-Bit ELF V2 ABI specification v2 section 3.8.3). "Compilers should generate a traceback table following the end of the code for every function." GCC has options to completely disable or expand the content in the table, via the options "- mtraceback={no,part,full}". Thus, the amount of content after that last blr could vary significantly. Thanks, -Will