stacking adjustment code #1

aeruder · 2015-10-05T20:04:40Z

Daniel, talked with you on the openocd channel. Could you please try these changes? backtrace should work on all threads after this adjustment.

Some targets (Cortex M) require more complicated calculations for turning the stored stack pointer back into a process stack pointer. For example, the Cortex M stores a bit in the auto-stacked xPSR indicating that alignment had to be performed and an additional 4 byte padding is present before the exception stacking. This change only sets up the framework for Cortex-M unstacking and does not add Cortex-M support. Note: this also fixes the alignment calculation nearly addressed by change #2301 entitled rtos/rtos.c: fix stack alignment calculation. Updated calculation is in rtos_generic_stack_align. Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com> Cc: Paul Fertser <fercerpav@gmail.com> Cc: Andreas Fritiofson <andreas.fritiofson@gmail.com> Cc: Evan Hunter <evanhunter920@gmail.com> Cc: Jon Burgess <jburgess777@gmail.com>

In the case that the STKALIGN bit is set on Cortex M processors, on entry to an exception - the processor can store an additional 4 bytes of padding before regular stacking to achieve 8-byte alignment on exception entry. In the case that this padding is present, the processor will set bit (1 << 9) in the stacked xPSR register. Use the new calculate_process_stack callback to take into account the xPSR register and use it on the standard Cortex_M3 stacking. Note: Change #2301 had some misinformation regarding the padding. On Cortex-M the padding is stored BEFORE stacking so xPSR is always available at a fixed offset. Tested on a Cortex-M0+ (Atmel SAMR21) board which has STKALIGN fixed to a '1' such that this alignment always occurs on non-aligned stacks. Behavior of xPSR verified via the (bad-sorry) assembly program below by setting a breakpoint on the SVC_Handler symbol. The first time SVC_Handler is triggered the stack was 0x20000ff8, the second time SVC_Handler is triggered the stack was 0x20000ffc. Note that in both cases the interrupt handler gets 0x20000fd8 for a stack pointer. GDB exerpt: Breakpoint 1, 0x000040b6 in Reset_Handler () (gdb) hbreak SVC_Handler Hardware assisted breakpoint 2 at 0x40f8 (gdb) cont Continuing. Breakpoint 2, 0x000040f8 in SVC_Handler () (gdb) print $msp $3 = (void *) 0x20000fd8 (gdb) x/9w $msp 0x20000fd8: 0x1 0x2 0x3 0x4 0x20000fe8: 0x88160082 0xa53 0x40ce 0x21000000 0x20000ff8: 0x0 (gdb) cont Continuing. Breakpoint 2, 0x000040f8 in SVC_Handler () (gdb) print $msp $4 = (void *) 0x20000fd8 (gdb) x/9w $msp 0x20000fd8: 0x1 0x2 0x3 0x4 0x20000fe8: 0x88160082 0xa53 0x40e8 0x21000200 0x20000ff8: 0x0 Assembly program: .cpu cortex-m0plus .fpu softvfp .thumb .syntax unified .section .vectors @ pvStack: .word 0x20001000 @ pfnReset_Handler: .word Reset_Handler + 1 @ pfnNMI_Handler: .word 0 @ pfnHardFault_Handler: .word 0 @ pfnReservedM12: .word 0 @ pfnReservedM11: .word 0 @ pfnReservedM10: .word 0 @ pfnReservedM9: .word 0 @ pfnReservedM8: .word 0 @ pfnReservedM7: .word 0 @ pfnReservedM6: .word 0 @ pfnSVC_Handler: .word SVC_Handler + 1 .section .text .global Reset_Handler Reset_Handler: cpsie i ldr r0, .stack_start ldr r2, .stack_last eors r1, r1 .loop_clear: str r1, [r0] adds r0, r0, #4 cmp r0, r2 bne .loop_clear subs r2, r2, #4 mov sp, r2 movs r0, daniel-k#1 movs r1, daniel-k#2 movs r2, daniel-k#3 movs r3, #4 svc #0 ldr r0, .stack_start ldr r2, .stack_last eors r1, r1 .loop_clear2: str r1, [r0] adds r0, r0, #4 cmp r0, r2 bne .loop_clear2 mov sp, r2 movs r0, daniel-k#1 movs r1, daniel-k#2 movs r2, daniel-k#3 movs r3, #4 svc #0 .loop: b .loop .align 4 .stack_start: .word 0x20000f00 .stack_last: .word 0x20000ffc @ first call - 0x2000fff8 -- should already be aligned @ second call - 0x2000fffc -- should hit the alignment code .global SVC_Handler SVC_Handler: bx lr Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com> Cc: Paul Fertser <fercerpav@gmail.com> Cc: Andreas Fritiofson <andreas.fritiofson@gmail.com> Cc: Evan Hunter <evanhunter920@gmail.com> Cc: Jon Burgess <jburgess777@gmail.com>

daniel-k · 2015-10-06T07:59:42Z

@aeruder
Your patches seem to work.

before:

(gdb) thr 2
[Switching to thread 2 (Thread 2)]
#0  mutex_lock (mutex=0x200001c0 <_rx_mutex>) at [...]
53  }
(gdb) bt
#0  mutex_lock (mutex=0x200001c0 <_rx_mutex>) at [...]
#1  0x20002dfc in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

after:

(gdb) thr 2
[Switching to thread 2 (Thread 2)]
#0  mutex_lock (mutex=mutex@entry=0x200001c0 <_rx_mutex>) at [...]
53  }
(gdb) bt
#0  mutex_lock (mutex=mutex@entry=0x200001c0 <_rx_mutex>) at [...]
#1  0x0000063a in uart_stdio_read (
    buffer=0x200033b0 "~_'!\342\371m\307M\017\321\071\211%\314\377*\272\t\252ak\362\066\036\313\062,\350\035\001\357\v\274̷\346\070\225\347B\264\307E\314\357\347\354G\300\334\017\231\211\275I\033\037\212z$\024\273\035\306\062LH\255L\t\212e\177\025\234\002]\fO\331M\235\253\233\356\271!\321\rܡ\376Z\027I\024\252\221\r\333F\245\337\273\212\177\\m=!\322\366\240\204\226t_\214\206B\234Q\275\256\230go\024\304|\362]\205\303\034\255\311\061t\374\222)\222\321\024B\340\b>\336\341\245\033\347\023?m\233\345\315\327\213\004\264\377a%\016\352\370Wx\006\224\255\066]ê\226\312?\211\314\"\207\371\300\324\354{$\270ڮ\212\257\265U"..., count=1024)
    at [...]
#2  0x000000fe in _read_r (r=<optimized out>, fd=<optimized out>, buffer=<optimized out>, count=<optimized out>)
    at [...]
#3  0x00004cb8 in __sread ()
#4  0x00005b56 in __srefill_r ()
#5  0x00004c40 in __srget_r ()
#6  0x000019be in readline (size=5, buf=0x0 <interrupt_vector>)
    at [...]
#7  shell_run (shell_commands=0xf63 <main+50>, shell_commands@entry=0x0 <interrupt_vector>, 
    line_buf=0x0 <interrupt_vector>, 
    line_buf@entry=0x200007f8 <main_stack+1328> "\376`\346f\376", <incomplete sequence \370>, len=5, len@entry=128)
    at [...]
#8  0x00000f62 in main () at [...]

Stackpointer:

(gdb) p $sp
$2 = (void *) 0x20000738 <main_stack+1136>

In the case that the STKALIGN bit is set on Cortex M processors, on entry to an exception - the processor can store an additional 4 bytes of padding before regular stacking to achieve 8-byte alignment on exception entry. In the case that this padding is present, the processor will set bit (1 << 9) in the stacked xPSR register. Use the new calculate_process_stack callback to take into account the xPSR register and use it on the standard Cortex_M3 stacking. Note: Change #2301 had some misinformation regarding the padding. On Cortex-M the padding is stored BEFORE stacking so xPSR is always available at a fixed offset. Tested on a Cortex-M0+ (Atmel SAMR21) board which has STKALIGN fixed to a '1' such that this alignment always occurs on non-aligned stacks. Behavior of xPSR verified via the (bad-sorry) assembly program below by setting a breakpoint on the SVC_Handler symbol. The first time SVC_Handler is triggered the stack was 0x20000ff8, the second time SVC_Handler is triggered the stack was 0x20000ffc. Note that in both cases the interrupt handler gets 0x20000fd8 for a stack pointer. GDB exerpt: Breakpoint 1, 0x000040b6 in Reset_Handler () (gdb) hbreak SVC_Handler Hardware assisted breakpoint 2 at 0x40f8 (gdb) cont Continuing. Breakpoint 2, 0x000040f8 in SVC_Handler () (gdb) print $msp $3 = (void *) 0x20000fd8 (gdb) x/9w $msp 0x20000fd8: 0x1 0x2 0x3 0x4 0x20000fe8: 0x88160082 0xa53 0x40ce 0x21000000 0x20000ff8: 0x0 (gdb) cont Continuing. Breakpoint 2, 0x000040f8 in SVC_Handler () (gdb) print $msp $4 = (void *) 0x20000fd8 (gdb) x/9w $msp 0x20000fd8: 0x1 0x2 0x3 0x4 0x20000fe8: 0x88160082 0xa53 0x40e8 0x21000200 0x20000ff8: 0x0 Assembly program: .cpu cortex-m0plus .fpu softvfp .thumb .syntax unified .section .vectors @ pvStack: .word 0x20001000 @ pfnReset_Handler: .word Reset_Handler + 1 @ pfnNMI_Handler: .word 0 @ pfnHardFault_Handler: .word 0 @ pfnReservedM12: .word 0 @ pfnReservedM11: .word 0 @ pfnReservedM10: .word 0 @ pfnReservedM9: .word 0 @ pfnReservedM8: .word 0 @ pfnReservedM7: .word 0 @ pfnReservedM6: .word 0 @ pfnSVC_Handler: .word SVC_Handler + 1 .section .text .global Reset_Handler Reset_Handler: cpsie i ldr r0, .stack_start ldr r2, .stack_last eors r1, r1 .loop_clear: str r1, [r0] adds r0, r0, #4 cmp r0, r2 bne .loop_clear subs r2, r2, #4 mov sp, r2 movs r0, #1 movs r1, #2 movs r2, #3 movs r3, #4 svc #0 ldr r0, .stack_start ldr r2, .stack_last eors r1, r1 .loop_clear2: str r1, [r0] adds r0, r0, #4 cmp r0, r2 bne .loop_clear2 mov sp, r2 movs r0, #1 movs r1, #2 movs r2, #3 movs r3, #4 svc #0 .loop: b .loop .align 4 .stack_start: .word 0x20000f00 .stack_last: .word 0x20000ffc @ first call - 0x2000fff8 -- should already be aligned @ second call - 0x2000fffc -- should hit the alignment code .global SVC_Handler SVC_Handler: bx lr Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com> Cc: Paul Fertser <fercerpav@gmail.com> Cc: Andreas Fritiofson <andreas.fritiofson@gmail.com> Cc: Evan Hunter <evanhunter920@gmail.com> Cc: Jon Burgess <jburgess777@gmail.com>

Add new AARCH64 target and ARMv8 support files. This is an instantiation from the cortex_a files but modified to support 64bit ARMv8. Not all features are complete, notably breakpts and single stepping are not yet implemented. Currently it lets you halt of the processors, resume, dump the cpu registers and even get a stack trace with gdb. > halt invalid mode value encountered 5 target state: halted unrecognized psr mode: 0x5 target halted in ARM state due to debug-request, current mode: UNRECOGNIZED cpsr: 0x600001c5 pc: 0x00093528 MMU: disabled, D-Cache: disabled, I-Cache: disabled > targets TargetName Type Endian TapName State -- ------------------ ---------- ------ ------------------ ------------ 0* cpu0 aarch64 little cpu.dap halted > reg ===== arm v8 registers (0) r0 (/64): 0x00000000FFFFFFED (dirty) (1) r1 (/64): 0x00000000F76E4000 (2) r2 (/64): 0x0000000000000000 (3) r3 (/64): 0x0000000000010000 (4) r4 (/64): 0xFFFFFFC06E2939E1 (5) r5 (/64): 0x0000000000000018 (6) r6 (/64): 0x003A699CFB3C8480 (7) r7 (/64): 0x0000000053555555 (8) r8 (/64): 0x00FFFFFFFFFFFFFF (9) r9 (/64): 0x000000001FFEF992 (10) r10 (/64): 0x0000000000000001 (11) r11 (/64): 0x0000000000000000 (12) r12 (/64): 0x00000000000000F0 (13) r13 (/64): 0x00000000EFDFEAC8 (14) r14 (/64): 0x00000000F6DDA659 (15) r15 (/64): 0x0000000000000000 (16) r16 (/64): 0xFFFFFFC0000F9094 (17) r17 (/64): 0x0000000000000000 (18) r18 (/64): 0x0000000000000000 (19) r19 (/64): 0xFFFFFFC00087C000 (20) r20 (/64): 0x0000000000000002 (21) r21 (/64): 0xFFFFFFC000867C28 (22) r22 (/64): 0xFFFFFFC000916A52 (23) r23 (/64): 0xFFFFFFC00116D8B0 (24) r24 (/64): 0xFFFFFFC000774A0C (25) r25 (/64): 0x000000008007B000 (26) r26 (/64): 0x000000008007D000 (27) r27 (/64): 0xFFFFFFC000080450 (28) r28 (/64): 0x0000004080000000 (29) r29 (/64): 0xFFFFFFC00087FF20 (30) r30 (/64): 0xFFFFFFC000085114 (31) sp (/64): 0xFFFFFFC00087FF20 (32) pc (/64): 0xFFFFFFC000093528 (33) xPSR (/64): 0x00000000600001C5 And from gdb (gdb) bt #0 cpu_do_idle () at /mnt/host/source/src/third_party/kernel/3.14/arch/arm64/mm/proc.S:87 #1 0xffffffc000085114 in arch_cpu_idle () at /mnt/host/source/src/third_party/kernel/3.14/arch/arm64/kernel/process.c:107 #2 0x0000000000000000 in ?? () Change-Id: Iccb1d15c7d8ace7b9e811dac3c9757ced4d0f618 Signed-off-by: David Ung <davidu@nvidia.com>

Andrew Ruder added 3 commits October 5, 2015 14:54

riot: support latest cortex m stack adjustment code

bb69aa3

daniel-k mentioned this pull request Oct 6, 2015

cortex_m: Add debug symbols for OpenOCD/GDB thread support RIOT-OS/RIOT#4058

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

stacking adjustment code #1

stacking adjustment code #1

Uh oh!

aeruder commented Oct 5, 2015

Uh oh!

daniel-k commented Oct 6, 2015

Uh oh!

Uh oh!

stacking adjustment code #1

Are you sure you want to change the base?

stacking adjustment code #1

Uh oh!

Conversation

aeruder commented Oct 5, 2015

Uh oh!

daniel-k commented Oct 6, 2015

Uh oh!

Uh oh!