From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15514 invoked by alias); 20 Apr 2016 16:23:09 -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 15503 invoked by uid 89); 20 Apr 2016 16:23:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=annoyance, 8:on, intact, msp X-HELO: mail2.cimeq.qc.ca Received: from mail2.cimeq.qc.ca (HELO mail2.cimeq.qc.ca) (205.237.245.17) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Apr 2016 16:22:58 +0000 Received: from [10.0.0.14] (unknown [10.0.0.14]) by mail2.cimeq.qc.ca (Postfix) with ESMTPA id BAE005576F; Wed, 20 Apr 2016 12:24:01 -0400 (EDT) Subject: Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder To: Luis Machado , gdb-patches@sourceware.org References: <5706DA27.1070308@cimeq.qc.ca> <570C1119.9090909@codesourcery.com> From: James-Adam Renquinha Henri Message-ID: <5717ACDE.4070503@cimeq.qc.ca> Date: Wed, 20 Apr 2016 16:23:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570C1119.9090909@codesourcery.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00480.txt.bz2 > On 04/07/2016 05:07 PM, James-Adam Renquinha Henri wrote: >> I submitted it as a bug to the GNU ARM Embedded initially, see here for >> details: https://bugs.launchpad.net/gcc-arm-embedded/+bug/1566054 >> >> Basically, this patch allow gdb to unwind properly an extended stack >> frame, that is an exception frame with FPU state stacked. Additionally, >> because all Cortex-M variants have 2 stack pointers, the Main Stack >> Pointer (MSP) and the Process Stack Pointer (PSP), the code in the patch >> also check which stack was used prior to the exception. That way, >> backtraces work beautifully. >> >> In my original submission, I mentioned a known issue that I didn't try >> to fix *yet*, because that would involve a lot more work, and the impact >> is relatively minor: for a given outer frame, some FPU registers may not >> be reported correctly. I hope you don't mind too much. I consider the >> current patch still useful, because at least backtraces work, and it's >> an annoyance not to be able to get them. > > I have feeling people will mind. Ideally it should keep the old behavior > intact if possible. So if you can fallback to the old code, it should be > ok. Sorry I don't get it. The old code didn't work in the cases I'm providing a fix for, so falling back to the old behavior means just giving wrong results? *scratches head* As I said, getting the behavior 100% correct would require much more work, and I felt that it was better to provide an almost correct solution so others would benefit quickly of this fix. It might be more honest to report a warning to the user that s0-s16 and fpscr could be incorrect upon detection of an extended frame. Mind that the old situation was "I can't even backtrace past the (CPU) exception if I happen to use the FPU", so IMHO it's less harmful to give inaccurate FPU information. Of course I or someone else can work to get it 100% right and we can throw all that altogether if it's better that way. James-Adam Renquinha Henri, Ing. jr Ingénieur d'application CIMEQ INC.