From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9448 invoked by alias); 20 Apr 2016 23:14:40 -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 9397 invoked by uid 89); 20 Apr 2016 23:14:35 -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=armv7-m, armv6-m, armv7m, armv6m 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 23:14:25 +0000 Received: from [10.0.0.14] (unknown [10.0.0.14]) by mail2.cimeq.qc.ca (Postfix) with ESMTPA id 50A485576F; Wed, 20 Apr 2016 19:15:28 -0400 (EDT) Subject: Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder To: Tristan Gingold , Pedro Alves References: <5706DA27.1070308@cimeq.qc.ca> <570C1D85.1060706@redhat.com> Cc: gdb-patches@sourceware.org, Christopher Friedt From: James-Adam Renquinha Henri Message-ID: <57180D4F.1030001@cimeq.qc.ca> Date: Wed, 20 Apr 2016 23:14: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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2016-04/txt/msg00495.txt.bz2 Le 2016-04-14 02:34, Tristan Gingold a écrit : > >> On 11 Apr 2016, at 23:56, Pedro Alves wrote: >> >> Hi, >> >> [Adding a few folks who either worked on or expressed >> interest in this before.] >> >> On 04/07/2016 11: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. >>> >> >> Thanks for the patch. However, we should really add new target >> descriptions/features that describe these registers to gdb >> instead of looking them up by name. Please see: >> >> https://sourceware.org/ml/gdb-patches/2015-12/msg00273.html >> Hmmmm, er, I'm pretty sure you're referring to the `user_reg_map_name_to_regnum` calls, but I'm not sure what the info in the link is supposed to tell me. This is the first time I play into the guts of `gdb` and am confronted by its inner complexity, though. I wasn't aware of "target features", haha :P This is what I understand, please correct me if I'm wrong: - When using OpenOCD, gdb gets a target description while communicating with the server, so it knows the other registers like "psp", "control", "fpscr" and other system registers exist. When using Qemu, gdb uses the "org.gnu.gdb.arm.m-profile" feature from binutils-gdb and the system registers are lacking from the XML file. This is the problem Christopher Friedt had in the thread; - If the system registers were in "org.gnu.gdb.arm.m-profile", then we could rely on their presence and put them in the `gdb_regnum` enum in arch/arm.h and assign them fixed offsets, removing the need to get them by name; - By finding registers by name, we're dependent of the supplied target description and even getting PSP (which is always available on any Cortex-M core BTW) can fail, and the code I provided will crash. (I realized LR is accessible via `ARM_LR_REGNUM`. Ooops) I'm not sure to follow, but it seems the inclusion of the system registers into "org.gnu.gdb.arm.m-profile" is still an open question. My opinion is to include them, because all Cortex-M have them. This can be seen in B1.4 of the ARMv6-M Reference Manual: The ARMv6-M profile has the following registers closely coupled to the processor: - General purpose registers R0-R12. - Two Stack Pointer registers, SP_main and SP_process. These are banked versions of SP, also described as R13. - The Link Register, LR also described as R14. - The Program Counter, PC, sometimes described as R15. - Status registers for flags, execution state bits, and the current exception number. - A mask register, PRIMASK, used to manage the prioritization scheme for exceptions and interrupts. - A control register, CONTROL that identifies the current stack. (later, they define SP_main as synonymous to MSP, and likewise for SP_process with PSP) Cortex-M0 and Cortex-M0+ are based on the ARMv6-M profile, and that profile is upward compatible with the ARMv7-M profile which is used in the Cortex-M3 and Cortex-M4(F): code compiled for Cortex-M0 can run on any Cortex-M. Meaning, ARMv6-M is the lowest common denominator of all Cortex-M. If the ARMv6-M architecture has these system registers, then all Cortex-M have them. >> And see more in this earlier attempt at getting the unwinder working: >> >> https://sourceware.org/ml/gdb-patches/2014-09/msg00649.html >> >> Tristan also wrote yet another patch for the same, as mentioned at: >> >> https://sourceware.org/ml/gdb-patches/2015-12/msg00281.html >> >> Tristan, did you ever manage to post that? > > Not yet. But I have tested it with two different probes. > >> Lots of duplicated effort. :-/ :-( > > Indeed. But we know that the common part is correct! > > Tristan. > > Well, technically the efforts are not entirely duplicated, for the scope of my patch is a bit broader, it deals with the FPU (found on Cortex-M4F), too. :) James-Adam Renquinha Henri, Ing. jr Ingénieur d'application CIMEQ INC.