From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92713 invoked by alias); 4 Aug 2016 07:04:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 92696 invoked by uid 89); 4 Aug 2016 07:04:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Application, credits, H*x:Build, HX-Priority:Normal X-HELO: mail2.securitas-direct.com Received: from mail2.securitas-direct.com (HELO mail2.securitas-direct.com) (195.170.189.96) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 04 Aug 2016 07:04:03 +0000 Received: from mail.securitas-direct.com (unknown [91.199.64.45]) by Websense Email with ESMTPS id BD709A47F5532 for ; Thu, 4 Aug 2016 09:03:59 +0200 (CEST) Received: from smtp.notes.na.collabserv.com ([192.155.248.67]) by mail.securitas-direct.com with ESMTP; 04 Aug 2016 09:03:59 +0200 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Thu, 4 Aug 2016 07:03:46 -0000 Received: from us1a3-smtp05.a3.dal06.isc4sb.com (10.146.71.159) by smtp.notes.na.collabserv.com (10.106.227.16) with smtp.notes.na.collabserv.com ESMTP; Thu, 4 Aug 2016 07:03:44 -0000 X-IBM-Helo: us1a3-smtp05.a3.dal06.isc4sb.com X-IBM-MailFrom: fredrik.hederstierna@verisure.com X-IBM-RcptTo: qiyaoltc@gmail.com;arenquinha@cimeq.qc.ca;gdb-patches@sourceware.org Received: from us1a3-mail13.a3.dal06.isc4sb.com ([10.146.77.97]) by us1a3-smtp05.a3.dal06.isc4sb.com with ESMTP id 2016080407034353-85169 ; Thu, 4 Aug 2016 07:03:43 +0000 MIME-Version: 1.0 Sensitivity: In-Reply-To: References: , Subject: Re: Re: [PATCH] Fix exception unwinding for ARM Cortex-M From: "Fredrik Hederstierna" To: James-Adam Renquinha Henri Cc: Yao Qi , gdb-patches@sourceware.org Date: Thu, 04 Aug 2016 07:04:00 -0000 X-LLNOutbound: False X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 x-cbid: 16080407-0327-0000-0000-0000000F26FE X-IBM-ISS-SpamDetectors: Score=0.437038; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.437038; ST=0; TS=0; UL=0; ISC= X-IBM-ISS-DetailInfo: BY=3.00005547; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000177; SDB=6.00739765; UDB=6.00347850; UTC=2016-08-04 07:03:45 x-cbparentid: 16080407-0328-0000-0000-0000001F3831 Message-Id: X-SW-Source: 2016-08/txt/msg00079.txt.bz2 Hi James-Adam, -----James-Adam Renquinha Henri wrote: ----- >Hi, I'm back from the dead. Nice to see you back :) >Seriously though, I was a bit too busy at work to pursue on this and >I=20 >didn't have a clear idea of where to start after the comments. >Moreover,=20 >as the patch did "just work" at my workplace, it was a bit difficult >to=20 >justify spending a lot more time digging information about target=20 >descriptions, how to determine what features are present on target, >etc. >So thanks to push toward the progress of this issue, apparently with=20 >your mail subject you successfully brought people that gives more=20 >specific guidance to get this done. I tried to check the status on your submission mid-July (https://sourceware= .org/ml/gdb/2016-07/msg00011.html), but since I got no directions from anyone in the community at that time, I = decided to try continue myself to get this fixed. We work alot with Cortex-M4F on a daily basis, and do really need this to b= e fixed. >Indeed, the patch looks really close to what I've done, to the point=20 >that I can see that, aside from a small refactoring, the changes >between=20 >our patches are mainly variable name changes and added comments. You=20 >really wrote your patch from scratch? You've got rid of the various=20 >calls to `user_reg_map_name_to_regnum', though, which is nice. Yes I wrote it from scratch, but I agree my patch looks similar to yours, a= s its implementing according to ARM Cortex-M spec, I guess it needs to be. But it absolutely helped me to have your ideas as s= tarting point to look at, to see where modifications needed to be done, so I do not mind if you would like to stand as co-author in the ChangeLog? If you have FSF GDB Assignment, or would like to apply for assignment, I can add your name to ChangeLog, its totally fine by me. The important thing for me is to get this fixed, and who gets the actual an= d final credits I do not mind. And I think it would be great if we could try to continue this work togethe= r, to get the remaining parts for Cortex-M support in GDB. The more people who are working on this, the better. I am not so experienced in GDB internals, and also seek guidance how to con= tinue go get the last parts in place. I think both to get GDB aware of MSP and PSP, and also FPCCR needs to be a = bigger change and are more complicated. My idea is to submit a bug entry in bugzilla on this, one issue for the MSP= /PSP support, another one for FPCCR, so we can get track of this, and someo= ne could be assigned. > > Cortex-M has two stack pointers: MSP (Main Stack Pointer) and PSP=20 >(Process Stack Pointer). > > This is not handled when GDB tries to backtrace in the exception=20 >stack unwinder. > > Meaning for eg. Cortex-M4F its not possible to get any call-stack=20 >backtrace if setting a breakpoint in ISR, and floating-point variable >was used. > >Actually, the info here is inaccurate: FPU context stacking and the=20 >MSP/PSP switch are two unrelated concepts. Meaning, you can fix the >code=20 >to deal with the PSP, but it still won't handle FPU register >unstacking. Correct, my plan now was to split the patch as Yao proposed. The the MSP/PSP-fix and FPU-fix would be two different patches. > > This patch was inspired by the great work done by James-Adam=20 >Renquinha Henri, submitted April this year. >Thanks :) > > > The next thing would then be to also add FPU context control reg=20 >FPCCR, which is needed for retrieving info on the FPU lazy stacking. > > Though its complicated I think and I will try to investigate an=20 >'arm-m-fpu.xml' profile further, if this is solution perhaps. > >It indeed is just a bit more complicated. Let me summarize what needs >to=20 >be done. Have the ARMv7-M Architecture Reference Manual handy, see >B1.5.7. > >- Check if lazy stacking is enabled (FPCCR.LSPEN =3D=3D 1). If it's not, >the=20 >case is uncomplicated, registers are stacked as usual >- If lazy stacking is active (FPCCR.LSACT =3D=3D 1), the extended stack >has=20 >space reserved for the FPU registers (S0-S15, FPSCR), but there are >not=20 >stacked, they are still in FPU registers unmodified. > >So that adds more random fetches from "memory" of the target, because > >these are memory-mapped. > >ARM gives some example scenarios with chronograms of some important >bits=20 >with stacking information [1]. Yes, my idea was that GDB needs to be aware of FPCCR, so we need probably a= n new XML profile feature for this, just as for PSP/MSP. But you are correct, its way more complicated. See also ARM Application Not= e I'm referring to in my patch comments. > > ChangeLog entry should cover what do you change on the function >level. > > Please read https://sourceware.org/gdb/wiki/ContributionChecklist > >If only I knew that checklist! I searched for something like this, >but=20 >maybe it didn't use the correct search terms, I didn't find it. If you want to stand as co-author in ChangeLog, its totally fine by me, just give me a hint if you have the FSF assignment done, and I also would be more than happy if you have time to continue your great= work, and get the last parts of unwinding support for Cortex-M in place. Thanks, and Kind Regards, Fredrik