From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41155 invoked by alias); 20 Apr 2016 16:27:23 -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 41139 invoked by uid 89); 20 Apr 2016 16:27:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=perfectly X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 20 Apr 2016 16:27:12 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1asuy6-0004EI-A7 from Luis_Gustavo@mentor.com ; Wed, 20 Apr 2016 09:27:10 -0700 Received: from [134.86.127.233] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.3.224.2; Wed, 20 Apr 2016 09:27:09 -0700 Reply-To: Luis Machado Subject: Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder References: <5706DA27.1070308@cimeq.qc.ca> <570C1119.9090909@codesourcery.com> <5717ACDE.4070503@cimeq.qc.ca> To: James-Adam Renquinha Henri , From: Luis Machado Message-ID: <5717ADDD.30908@codesourcery.com> Date: Wed, 20 Apr 2016 16:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5717ACDE.4070503@cimeq.qc.ca> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00481.txt.bz2 On 04/20/2016 11:22 AM, James-Adam Renquinha Henri wrote: >> 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* > I may have misunderstood. Is the known issue something caused by the new patch (a regression) or something that is still broken but is not being addressed by this patch at this time? If the latter, it is perfectly fine. I thought it was the former. > 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.