This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: James-Adam Renquinha Henri <arenquinha at cimeq dot qc dot ca>, <gdb-patches at sourceware dot org>
- Date: Wed, 20 Apr 2016 11:27:09 -0500
- Subject: Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder
- Authentication-results: sourceware.org; auth=none
- References: <5706DA27 dot 1070308 at cimeq dot qc dot ca> <570C1119 dot 9090909 at codesourcery dot com> <5717ACDE dot 4070503 at cimeq dot qc dot ca>
- Reply-to: Luis Machado <lgustavo at codesourcery dot com>
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
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
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
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.