Due to a misunderstanding about SP being the same as FP on ARM
pkg/runtime/memmove_arm.s is corrupting its parameters instead of
saving data in its stack frame.

TEXT runtime·memmove(SB), 7, $4-12
_memmove:
        MOVW    to+0(FP), R(TS)
        MOVW    from+4(FP), R(FROM)
        MOVW    n+8(FP), R(N)

[snip]

_b4aligned:                             /* is source now aligned? */
        AND.S   $3, R(FROM), R(TMP)
        BNE     _bunaligned

        ADD     $31, R(TS), R(TMP)      /* do 32-byte chunks if possible */
        MOVW    R(TS), savedts+4(SP)    // <------ THIS IS WRONG!
_b32loop:
        CMP     R(TMP), R(TE)
        BLS     _b4tail

Which disassembles to

0003a370 <runtime.memmove>:
   3a370:       e52de008        str     r14, [r13, #-8]!
   3a374:       e59d000c        ldr     r0, [r13, #12] // to argument
   3a378:       e59db010        ldr     r11, [r13, #16]
   3a37c:       e59dc014        ldr     r12, [r13, #20]

[snip]

   3a3b0:       e21bc003        ands    r12, r11, #3
   3a3b4:       1a000015        bne     3a410 <runtime.memmove+0xa0>
   3a3b8:       e280c01f        add     r12, r0, #31
   3a3bc:       e58d000c        str     r0, [r13, #12] // should be #4
   3a3c0:       e158000c        cmp     r8, r12
   3a3c4:       9a000002        bls     3a3d4 <runtime.memmove+0x64>

It was clearly the intention of the author to save R(TS) in the stack
frame (otherwise why allocate it) but actually it is being saved in the
to argument. In fact the allocated word in the stack frame 4(R13) is
never used.

I'm unclear whether called functions are allowed to corrupt their
arguments in the go calling convention or not. However Dave Cheney the
original author of this code agreed that it was a bug and should be
fixed.

Which compiler are you using (5g, 6g, 8g, gccgo)?

5g

Which operating system are you using?

linux arm

Which version are you using?  (run 'go version')

go version devel +77be25034f84 Fri Jul 19 01:22:26 2013 +0400 linux/amd64