From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id 37C833858C55 for ; Thu, 13 Oct 2022 12:24:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 37C833858C55 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29DAlKRL008870; Thu, 13 Oct 2022 14:24:22 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3k6h7v0mu4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Oct 2022 14:24:22 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D664910002A; Thu, 13 Oct 2022 14:24:16 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 8CE47229A8F; Thu, 13 Oct 2022 14:24:16 +0200 (CEST) Received: from [10.252.14.104] (10.75.127.46) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2375.31; Thu, 13 Oct 2022 14:24:15 +0200 Message-ID: <06178385-10b2-83cf-c0ff-aa6b90dfe2ac@foss.st.com> Date: Thu, 13 Oct 2022 14:24:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: [PATCH v2] gdb/arm: Stop unwinding on error, but do not assert Content-Language: en-US To: Pedro Alves , References: <20221013091740.645783-1-torbjorn.svensson@foss.st.com> <9cc66b68-94b4-ed24-f4b5-93a441b8a70d@palves.net> From: Torbjorn SVENSSON In-Reply-To: <9cc66b68-94b4-ed24-f4b5-93a441b8a70d@palves.net> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.46] X-ClientProxiedBy: SFHDAG2NODE3.st.com (10.75.127.6) To SHFDAG1NODE3.st.com (10.75.129.71) 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-10-13_08,2022-10-13_01,2022-06-22_01 X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, 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 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: Thu, 13 Oct 2022 12:24:28 -0000 Hi Pedro, On 2022-10-13 13:21, Pedro Alves wrote: > On 2022-10-13 10:17 a.m., Torbjörn SVENSSON via Gdb-patches wrote: > >> + /* Unwind of this frame is not possible. Return outer_frame_id to stop the >> + unwinding. */ >> + if (cache == NULL) >> + { >> + *this_id = outer_frame_id; >> + return; >> + } > > Please let's not add more uses of outer_frame_id if we can avoid it. We're getting > close to eliminating it. Can a cache object still be returned, and then a frame id > be successfully computed? The problem is that it's not always possible to know what registers that was written on the stack or if there was padding between 2 frames on the stack. If a cache object is returned, wouldn't that imply that the content of this frame is supposed to be valid? > You can stop the unwinding in some other way. For example, arm_m_exception_cache has a few > of these: > > /* Terminate any further stack unwinding by referring to self. */ > arm_cache_set_active_sp_value (cache, tdep, sp); > return cache; > > (Not sure exactly how that works.) I'm behind the some of those statements in arm-tdep.c, but the construct was copied from some other place in the GDB sources. I think there is some code in GDB that checks if 2 frames have the same SP value and in that case, stops the unwinding. > Alternatively, you can implement a frame_unwind::stop_reason callback and return > UNWIND_OUTERMOST, which is already done in arm-tdep.c in other scenarios too. Is it guaranteed that the prev_register method won't be called for a cache object that have the UNWIND_OUTERMOST stop reason? If so, I suppose the struct arm_prologue_cache could be extended with another member that indicates if the frame was successfully unwinded or if there were some problem and the UNWIND_OUTERMOST should be returned. Would this be okay? Kind regards, Torbjörn