From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id R/wULqoKN2OXnQIAWB0awg (envelope-from ) for ; Fri, 30 Sep 2022 11:26:34 -0400 Received: by simark.ca (Postfix, from userid 112) id B00911E112; Fri, 30 Sep 2022 11:26: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=ZNHBMCn7; 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,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 3E05E1E07B for ; Fri, 30 Sep 2022 11:26:34 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 941DF3852771 for ; Fri, 30 Sep 2022 15:26:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 941DF3852771 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1664551593; bh=eAyq+mevox9xiME3zJStscKBhJsFxPjoSsWAc8+NwnU=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ZNHBMCn7nDNN4Y1zpzAcTTeCraRfl8Hb0ZXkYO8JECiqTUrGkKHm7430Uo3MTya27 ASeAy++t6UD2qGG5bOjfKgwyzTjPAJI3ygCn7t17tW1uHUKhYv+UNV08t1Dx8bBfMW NelUMiv60GurafTGwMxUZYjpUxB3u9iDFykvxWg0= Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id 46344385C404 for ; Fri, 30 Sep 2022 15:26:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46344385C404 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 28UD1l12032442; Fri, 30 Sep 2022 17:26:03 +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 3jwxnmhpka-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Sep 2022 17:26:03 +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 472BD10002A; Fri, 30 Sep 2022 17:26:02 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 30E4E233C8A; Fri, 30 Sep 2022 17:26:02 +0200 (CEST) Received: from [10.252.30.137] (10.75.127.50) 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; Fri, 30 Sep 2022 17:26:01 +0200 Message-ID: <0aa66097-a196-6ca8-e47f-45fae4482cfa@foss.st.com> Date: Fri, 30 Sep 2022 17:26:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH v3] gdb/arm: Handle lazy FPU register stacking Content-Language: en-US To: Pedro Alves , References: <20220927190944.201748-1-torbjorn.svensson@foss.st.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.50] 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.528,FMLib:17.11.122.1 definitions=2022-09-30_04,2022-09-29_03,2022-06-22_01 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: Torbjorn SVENSSON via Gdb-patches Reply-To: Torbjorn SVENSSON Cc: tom@tromey.com, brobecker@adacore.com Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi, On 2022-09-30 17:13, Pedro Alves wrote: > On 2022-09-27 8:09 p.m., Torbjörn SVENSSON via Gdb-patches wrote: >> Read LSPEN, ASPEN and LSPACT bits from FPCCR and use them for the >> first exception frame. All frames after will always have the FPU >> registers on the stack, regadless if lazy stacking is active or >> inactive. See "Lazy context save of FP state", in B1.5.7, also ARM >> AN298, supported by Cortex-M4F architecture for details on lazy FPU >> register stacking. The same conditions are valid for other Cortex-M >> cores with FPU. >> >> This patch has been verified on a STM32F4-Discovery board by: >> a) writing a non-zero value (lets use 0x1122334455667788 as an >> example) to all the D-registers in the main function >> b) configured the SysTick to fire >> c) in the SysTick_Handler, write some other value (lets use >> 0x0022446688aaccee as an example) to one of the D-registers (D0 as >> an example) and then do "SVC #0" >> d) in the SVC_Handler, write some other value (lets use >> 0x0099aabbccddeeff) to one of the D-registers (D0 as an example) >> >> In GDB, suspend the execution in the SVC_Handler function and compare >> the value of the D-registers for the SVC_handler frame and the >> SysTick_Handler frame. With the patch, the value of the modified >> D-register (D0) should be the new value (0x009..eff) on the >> SVC_Handler frame, and the intermediate value (0x002..cee) for the >> SysTick_Handler frame. Now compare the D-register value for the >> SysTick_Handler frame and the main frame. The main frame should >> have the initial value (0x112..788). > > I suspect pasting a short GDB session here instead of prose may make this > easier to grok. > >> static bool arm_debug; >> +static bool force_fpu_regs_from_stack = false; >> >> /* Print an "arm" debug statement. */ >> >> @@ -3337,6 +3338,17 @@ struct frame_unwind arm_stub_unwind = { >> arm_stub_unwind_sniffer >> }; >> >> + >> +/* The first time an exception frame is seen, the lazy stacking of the FPU >> + registers should be considered. Any following exception frames should not >> + consider the lazy stacking as the values will be put on the stack before >> + branching to the nested exception handler. */ >> +static void >> +reset_force_fpu_regs_from_stack () >> +{ >> + force_fpu_regs_from_stack = false; >> +} >> + > > Is there really no self-contained way to tell that a frame is a "following frame > after lazy stack has been enabled" ? E.g., can we look at the address in > FPCAR and decide based on it, compared to the current frame address, or something > like that? As the function is Cortex-M specific, I suppose it would be fine to assume that the stack always grows downwards. With this assumption, I suppose we could compare the value in FPCAR with the value of $sp of the frame to be unwinded after the current frame. - If the value is lower, then I think it's safe to assume that the stacked content should be used. - If the value is greater, then I think it's safe to assume that it's up to LSPACT, LSPEN and ASPEN to define if it's going to be register or stacked content that should be used. Does this sound reasonable? I'll try to find some time later today or in the weekend to give it a try. Kind regards, Torbjörn