On Wed, 28 Oct 2015 09:13:19 +0100 Andreas Fritiofson <andreas.fritiof...@gmail.com> wrote:
> Hi! > > Have you seen http://openocd.zylin.com/3003 and related patches? > > /Andreas I hadn’t before, but I have had a look at them now (as you might have noticed, I put code review comments on both 3002 and 3003). Thanks! Unfortunately, while they do fix the basic logic bugs with Cortex-M stack handling, they don’t really address the third issue: other frame formats. What do I do if I want to use the FPU, and therefore my stack frame contains floating point registers? There’s no way I can tell OpenOCD about that frame format without recompiling from source and maintaining site-local patches to C code. The big question I wanted to address was if any of the core OpenOCD people had any thoughts about whether a refactor in that area to perhaps move declaring the stack layout into TCL (or, even better, implementing the actual stack decoding logic in TCL, which would allow more interesting variable stack layouts) would make sense? As an example of “more interesting variable stack layouts”: consider the case of an FPU-equipped microcontroller running FreeRTOS and using the Cortex-M automatic FPU state preservation logic, along with a bit test on LR in the FreeRTOS context switch function. If the specific task being suspended uses the FPU, then LR bit 4 is cleared by the CPU on exception entry and a combination of CPU and firmware code make sure to save the 32 floating point registers. If the specific task being suspended doesn’t use the FPU, then LR bit 4 is set on exception entry and those 32 register slots, plus the time taken to write them, are all saved for that task. But that means the stack layout looks quite different for different tasks, and the saved exception return code from LR tells you which shape you’re looking at. This is the sort of logic that seems like it ought to be defined in the configuration file rather than hard-coded in OpenOCD. Check FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c function xPortPendSVHandler for an example of where this happens. Although I initially wanted this for a custom port, the same sort of complexity even shows up in one of the official ports. -- Christopher Head
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel