From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sG7jJVswfGLguQUAWB0awg (envelope-from ) for ; Wed, 11 May 2022 17:53:31 -0400 Received: by simark.ca (Postfix, from userid 112) id 971C21E220; Wed, 11 May 2022 17:53:31 -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=yxd/7GyR; 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 D0F0A1E143 for ; Wed, 11 May 2022 17:53:30 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8068D3839412 for ; Wed, 11 May 2022 21:53:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8068D3839412 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1652306010; bh=PT2QopaNBIAJYQiNpgVdUfKITDhyB1s4ERPNVL5hFNQ=; h=To:Date:In-Reply-To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=yxd/7GyREDy6wQpSWv06FyNNGJmhEm5tSFrluvouxOWE0Bmc0XwYxcAQRowKfAbB6 q/QDJdJ/VKM1yuSAcSwdFpsDET8XScm7ptUGaoahRWaMeaJKPOubhXWKXo5qqtMabh qyCQ4HMsCHP+DJI7NzZI0jxBJMhgWBK16ZFVDV9c= Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 00090394FC19 for ; Wed, 11 May 2022 21:53:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 00090394FC19 Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24BL0piQ040503; Wed, 11 May 2022 21:53:02 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g0kbvjfcs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 May 2022 21:53:02 +0000 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 24BLcxhu035740; Wed, 11 May 2022 21:53:01 GMT Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g0kbvjfcp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 May 2022 21:53:01 +0000 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 24BLhHmj022728; Wed, 11 May 2022 21:53:01 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma01wdc.us.ibm.com with ESMTP id 3fwgd9f205-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 May 2022 21:53:01 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 24BLr0l244368152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 May 2022 21:53:00 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8B97628064; Wed, 11 May 2022 21:53:00 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AB6BD2805E; Wed, 11 May 2022 21:52:59 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.152.172]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 11 May 2022 21:52:59 +0000 (GMT) Message-ID: To: Pedro Alves , will schmidt , Kevin Buettner , gdb-patches@sourceware.org Date: Wed, 11 May 2022 14:52:58 -0700 In-Reply-To: <40d76dce-1331-3af5-f6f2-0de9d956d76c@palves.net> References: <76bea9ad010a71ea5e2c7fd78f818bdb399810a6.camel@us.ibm.com> <20220506110826.5e16c8b6@f35-zws-1> <70a877cc-2f35-3924-6717-9d519c2730c5@palves.net> <099c8f8d8729a0051f83a034d62c18f03c789167.camel@vnet.ibm.com> <37d2a4b6a57b62662f0417f123bda6ba48066554.camel@vnet.ibm.com> <40d76dce-1331-3af5-f6f2-0de9d956d76c@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-GUID: X7T4onhc7tFm_Msxj6bOCGoZ39USkPQC X-Proofpoint-ORIG-GUID: KHOoIKWNulU4JQ56dKFuj3ZSFtg65lY2 Subject: RE: [PATCH V2] PowerPC: fix for gdb.base/eh_return.exp 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-11_07,2022-05-11_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 adultscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205110095 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: Carl Love via Gdb-patches Reply-To: Carl Love Cc: Rogerio Alves Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Pedro: I reached out to the GCC team to see if I could get more information on this. I have inserted the answers to your questions below in your reply. On Tue, 2022-05-10 at 12:43 +0100, Pedro Alves wrote: > On 2022-05-09 21:57, will schmidt wrote: > > 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...). > > OOC, does the ABI specify that the size of the function covers the > Traceback information as well? The size of the function includes the traceback table. > I didn't find anything about that, and my initial > reading of the wording used in the ABI "following the end of the > code" would > make me think that it should not. If it wasn't, then of course > disassembling > a function would not run into the table. Maybe it's done this way > today to make it > easier on the linker. > > Regardless, I was wondering whether there's any way for GDB to know > that > a given PC range is a traceback table, so that it wouldn't try to > disassemble > such a range as instructions? GDB would have to determine the PC range of the traceback table. You start in the function and scan for a word of zeros that falls between the function start address and the function start address plus the size of the function. So, if the traceback table was generated, you will find a word of zeros. In the case where the compiler flags were set to not generate the traceback table, there will not be a word of zeros before the function start address plus the size of the function. > The ABI you pointed out says: > > "Compilers should generate a traceback table following the end of the > code for every function. Debuggers > and exception handlers can locate the traceback tables by scanning > forward from the instruction address > at the point of interruption. The beginning of the traceback table is > marked by a word of zeroes, which is > an illegal instruction. If read-only constants are compiled into the > same section as the function code, they > must follow the traceback table. A word of zeroes as read-only data > must not be the first word following > the code for a function. A traceback table is word-aligned." > > Naively, we could use the "word of zeroes" marker to see where the > table starts, but it > wouldn't work when you're disassembling a PC range instead of the > whole function. Basically you have to scan thru the function to find the word of zeros. > > Is there perhaps some symbol that points to the start of the table, No > or some section with the list > of traceback tables in the program or some such? Unfortunately the answer is again no. I looked into the original problem report. The issue had to do with setting a break point on the last instruction in the function. This triggered an assert which was later fixed by commit 547ce8f00b "[gdb/backtrace] Fix printing of fortran string args". The commit adds a call to select_frame in print_frame_args() in gdb/stack.c. I tried to dig into the specifics of how this change fixed the issue but I don't see exactly how it fixed things. Not sure knowing the details of the fix is really necessary in this case, just interesting. The test was added to check if the assert failed in the future due to some code change. The key thing is setting the break on the last instruction in the function and verifying that gdb reaches the breakpoint. So, disabling the traceback table generation on PowerPC allows the existing expect test to set the breakpoint on the last instruction in the function, blr for PowerPC. The test now behaves the same on PowerPC as it does on other architectures. I don't see that not generating the traceback table on PowerPC would somehow invalidate the ability of this test to verify the gdb code had not regressed. I will fix up version 2 of the patch that disables the traceback table per Will's comments and post version 3. Carl Love