| 2016-04-04 23:22:16 |
James-Adam Renquinha Henri |
bug |
|
|
added bug |
| 2016-04-04 23:22:16 |
James-Adam Renquinha Henri |
attachment added |
|
patch https://bugs.launchpad.net/bugs/1566054/+attachment/4623719/+files/patch |
|
| 2016-04-04 23:33:54 |
James-Adam Renquinha Henri |
description |
`arm-none-eabi-gdb`, as of 7.11, cannot show backtraces properly when using PSP & MSP and/or FPU is active after the debugged program receives any exception. The following shows the issues encountered.
How to reproduce:
-----
FPU case: use a Cortex-M4 core with FPU activated (
Behavior with code using multiple stacks (PSP & MSP):
-----
`gdb` doesn't know about the Process Stack Pointer, so it continues using the current (Main) stack pointer and it gets into the void. Example session:
(gdb) bt
#0 SysTick_Handler () at systick.cpp:8
#1 <signal handler called>
#2 0x000007b2 in ?? ()
#3 0x00000000 in ?? ()
Behavior with FPU active (used):
-----
`gdb` doesn't know the other EXC_RETURN codes involving the extended frame type, so it gets interpreted as a thumb address, again leading into the void. Example session:
(gdb) bt
#0 SysTick_Handler () at systick.cpp:8
#1 0xffffffe8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The fix provided (patch attached) is manifold and perform the following:
- Correctly recognize the other EXC_RETURN code involving the extended exception stack frame;
- On an exception stack frame, check LR[3:0] to determine which stack was used before the exception occured and use it;
- On an exception stack frame, check LR[4] to determine if the FPU was used and adjust the stack pointer and possibly load the stacked FPU registers. But please take note of the known issues below.
The fix was tested with the possible combinations of usage of PSP/FPU and the result of `info all-registers` on various frames thoroughly visually inspected.
Apply patch in gdb-7.11 with `patch -p1 < patch`.
Known Issue:
-----
As noted in a comment in the patch, the lazy stacking feature is not accounted for, and as a result may give incorrect results for FPU registers in a upper frame depending on whether the registers are actually stacked or not. However the backtrace is still functional. Actually, I verified that once the Cortex-M4 core stacks the FPU registers (for instance, upon execution of a FPU instruction in a exception handler), `gdb` reports them correctly. |
`arm-none-eabi-gdb`, as of 7.11, cannot show backtraces properly when using PSP & MSP and/or FPU is active after the debugged program receives any exception. The following shows the issues encountered.
How to reproduce:
-----
FPU case: use a Cortex-M4 core with FPU activated (CP10 = CP11 = 3), breakpoint in any exception handler.
PSP case: any Cortex-M, initialize PSP and set bit 2 of CONTROL, breakpoint in any exception handler.
Example code to initialize both CONTROL and PSP (__main_stack_end__ must be defined):
.global __main_stack_end__
mrs r0, CONTROL
mov r1, #2
orr r0, r0, r1
mov r1, sp
ldr r2, =__main_stack_end__
msr PSP, r1
msr CONTROL, r0
msr MSP, r2
Behavior with code using multiple stacks (PSP & MSP):
-----
`gdb` doesn't know about the Process Stack Pointer, so it continues using the current (Main) stack pointer and it gets into the void. Example session:
(gdb) bt
#0 SysTick_Handler () at systick.cpp:8
#1 <signal handler called>
#2 0x000007b2 in ?? ()
#3 0x00000000 in ?? ()
Behavior with FPU active (used):
-----
`gdb` doesn't know the other EXC_RETURN codes involving the extended frame type, so it gets interpreted as a thumb address, again leading into the void. Example session:
(gdb) bt
#0 SysTick_Handler () at systick.cpp:8
#1 0xffffffe8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The fix provided (patch attached) is manifold and perform the following:
- Correctly recognize the other EXC_RETURN code involving the extended exception stack frame;
- On an exception stack frame, check LR[3:0] to determine which stack was used before the exception occured and use it;
- On an exception stack frame, check LR[4] to determine if the FPU was used and adjust the stack pointer and possibly load the stacked FPU registers. But please take note of the known issues below.
The fix was tested with the possible combinations of usage of PSP/FPU and the result of `info all-registers` on various frames thoroughly visually inspected.
Apply patch in gdb-7.11 with `patch -p1 < patch`.
Known Issue:
-----
As noted in a comment in the patch, the lazy stacking feature is not accounted for, and as a result may give incorrect results for FPU registers in a upper frame depending on whether the registers are actually stacked or not. However the backtrace is still functional. Actually, I verified that once the Cortex-M4 core stacks the FPU registers (for instance, upon execution of a FPU instruction in a exception handler), `gdb` reports them correctly. |
|
| 2016-04-13 09:21:25 |
Tejas Belagod |
gcc-arm-embedded: status |
New |
Opinion |
|
| 2016-04-13 09:22:13 |
Tejas Belagod |
gcc-arm-embedded: assignee |
|
James-Adam Renquinha Henri (arenquinha) |
|
| 2017-11-08 12:01:12 |
Norbert Varga |
bug |
|
|
added subscriber Norbert Varga |
| 2018-07-24 04:46:52 |
xintianzhang |
description |
`arm-none-eabi-gdb`, as of 7.11, cannot show backtraces properly when using PSP & MSP and/or FPU is active after the debugged program receives any exception. The following shows the issues encountered.
How to reproduce:
-----
FPU case: use a Cortex-M4 core with FPU activated (CP10 = CP11 = 3), breakpoint in any exception handler.
PSP case: any Cortex-M, initialize PSP and set bit 2 of CONTROL, breakpoint in any exception handler.
Example code to initialize both CONTROL and PSP (__main_stack_end__ must be defined):
.global __main_stack_end__
mrs r0, CONTROL
mov r1, #2
orr r0, r0, r1
mov r1, sp
ldr r2, =__main_stack_end__
msr PSP, r1
msr CONTROL, r0
msr MSP, r2
Behavior with code using multiple stacks (PSP & MSP):
-----
`gdb` doesn't know about the Process Stack Pointer, so it continues using the current (Main) stack pointer and it gets into the void. Example session:
(gdb) bt
#0 SysTick_Handler () at systick.cpp:8
#1 <signal handler called>
#2 0x000007b2 in ?? ()
#3 0x00000000 in ?? ()
Behavior with FPU active (used):
-----
`gdb` doesn't know the other EXC_RETURN codes involving the extended frame type, so it gets interpreted as a thumb address, again leading into the void. Example session:
(gdb) bt
#0 SysTick_Handler () at systick.cpp:8
#1 0xffffffe8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The fix provided (patch attached) is manifold and perform the following:
- Correctly recognize the other EXC_RETURN code involving the extended exception stack frame;
- On an exception stack frame, check LR[3:0] to determine which stack was used before the exception occured and use it;
- On an exception stack frame, check LR[4] to determine if the FPU was used and adjust the stack pointer and possibly load the stacked FPU registers. But please take note of the known issues below.
The fix was tested with the possible combinations of usage of PSP/FPU and the result of `info all-registers` on various frames thoroughly visually inspected.
Apply patch in gdb-7.11 with `patch -p1 < patch`.
Known Issue:
-----
As noted in a comment in the patch, the lazy stacking feature is not accounted for, and as a result may give incorrect results for FPU registers in a upper frame depending on whether the registers are actually stacked or not. However the backtrace is still functional. Actually, I verified that once the Cortex-M4 core stacks the FPU registers (for instance, upon execution of a FPU instruction in a exception handler), `gdb` reports them correctly. |
`arm-none-eabi-gdb`, as of 7.11, cannot show backtraces properly when using PSP & MSP and/or FPU is active after the debugged program receives any exception. The following shows the issues encountered.
How to reproduce:
-----
FPU case: use a Cortex-M4 core with FPU activated (CP10 = CP11 = 3), breakpoint in any exception handler.
PSP case: any Cortex-M, initialize PSP and set bit 2 of CONTROL, breakpoint in any exception handler.
Example code to initialize both CONTROL and PSP (__main_stack_end__ must be defined):
.global __main_stack_end__
mrs r0, CONTROL
mov r1, #2
orr r0, r0, r1
mov r1, sp
ldr r2, =__main_stack_end__
msr PSP, r1
msr CONTROL, r0
msr MSP, r2
Behavior with code using multiple stacks (PSP & MSP):
-----
`gdb` doesn't know about the Process Stack Pointer, so it continues using the current (Main) stack pointer and it gets into the void. Example session:
(gdb) bt
#0 SysTick_Handler () at systick.cpp:8
#1 <signal handler called>
#2 0x000007b2 in ?? ()
#3 0x00000000 in ?? ()
Behavior with FPU active (used):
-----
`gdb` doesn't know the other EXC_RETURN codes involving the extended frame type, so it gets interpreted as a thumb address, again leading into the void. Example session:
(gdb) bt
#0 SysTick_Handler () at systick.cpp:8
#1 0xffffffe8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The fix provided (patch attached) is manifold and perform the following:
- Correctly recognize the other EXC_RETURN code involving the extended exception stack frame;
- On an exception stack frame, check LR[3:0] to determine which stack was used before the exception occured and use it;
- On an exception stack frame, check LR[4] to determine if the FPU was used and adjust the stack pointer and possibly load the stacked FPU registers. But please take note of the known issues below.
The fix was tested with the possible combinations of usage of PSP/FPU and the result of `info all-registers` on various frames thoroughly visually inspected.
Apply patch in gdb-7.11 with `patch -p1 < patch`.
Known Issue:
-----
As noted in a comment in the patch, the lazy stacking feature is not accounted for, and as a result may give incorrect results for FPU registers in a upper frame depending on whether the registers are actually stacked or not. However the backtrace is still functional. Actually, I verified that once the Cortex-M4 core stacks the FPU registers (for instance, upon execution of a FPU instruction in a exception handler), `gdb` reports them correctly. |
|
| 2018-07-24 04:47:34 |
xintianzhang |
bug |
|
|
added subscriber xintianzhang |
| 2018-08-31 01:08:25 |
Robert North |
bug |
|
|
added subscriber Robert North |
| 2020-08-07 15:53:22 |
Myk Melez |
bug |
|
|
added subscriber Myk Melez |
