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 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 , CC: , References: <20220927190944.201748-1-torbjorn.svensson@foss.st.com> From: Torbjorn SVENSSON 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-Spam-Status: No, score=-6.2 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: Fri, 30 Sep 2022 15:26:15 -0000 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