SIGILL with ARM Go program on Raspberry Pi


I’m basically looking for an idea where to start looking for the bug…

I’m cross-compiling the following Azure application for managing Azure storage from Windows for using it on a Raspberry Pi in 32-bit mode under Debian Linux:

The environment variables for go build were set as follows:

$env:GOOS = "linux"
$env:GOARCH = "arm"
$env:GOARM= "5"

The resulting program can be executed in general on the Raspberry Pi, e.g. I can invoke it to get the usage message:

stm@raspberrypi:~$ ./azure-storage-azcopy -h
AzCopy 10.16.2
Project URL:

But when I attempt an actual operation it crashes:

stm@raspberrypi:~$ ./azure-storage-azcopy list
INFO: Authenticating to source using Azure AD
SIGILL: illegal instruction
PC=0x133ec m=5 sigcode=4
instruction bytes: 0x38 0x60 0x9f 0xe5 0x6 0x0 0x50 0xe1 0x6 0x0 0x0 0x9a 0x0 0x10 0xe0 0xe3

goroutine 1 [syscall]:
syscall.Syscall6(0x900137, 0x0, 0xfffffffd, 0x1, 0x0, 0x0, 0x0)
        C:/Program Files/Go/src/syscall/syscall_linux.go:90 +0x8 fp=0x1a8f7a8 sp=0x1a8f770 pc=0xd7264, {0x1a8f818, 0x2, 0x2})
        C:/Users/stm/go/pkg/mod/ +0x158 fp=0x1a8f7f0 sp=0x1a8f7a8 pc=0x41e7a4
        C:/Users/stm/go/pkg/mod/ +0x4c fp=0x1a8f820 sp=0x1a8f7f0 pc=0x41ed4c
        E:/Users/stm/Documents/GitHub/azure-storage-azcopy/common/credCache_linux.go:112 +0x1c fp=0x1a8f83c sp=0x1a8f820 pc=0x76f738*CredCache).HasCachedToken(0x151e3c0)
        E:/Users/stm/Documents/GitHub/azure-storage-azcopy/common/credCache_linux.go:69 +0x34 fp=0x1a8f860 sp=0x1a8f83c pc=0x76f560*UserOAuthTokenManager).getCachedTokenInfo(0x17ffa70, {0xbb2770, 0x151f7a0})
        E:/Users/stm/Documents/GitHub/azure-storage-azcopy/common/oauthTokenManager.go:513 +0x24 fp=0x1a8f9a4 sp=0x1a8f860 pc=0x783100*UserOAuthTokenManager).GetTokenInfo(0x17ffa70, {0xbb2770, 0x151f7a0})
        E:/Users/stm/Documents/GitHub/azure-storage-azcopy/common/oauthTokenManager.go:129 +0xd4 fp=0x1a8fad0 sp=0x1a8f9a4 pc=0x780ee4{0xbb2770, 0x151f7a0}, 0x3, {0x152eb40, 0x2e}, {0x0, 0x0}, 0x1, {0x0, {0x0, ...}, ...})
... <long stackdump for multiple threads> ...

I would like to understand the reason for the illegal instruction signal:

SIGILL: illegal instruction
PC=0x133ec m=5 sigcode=4
instruction bytes: 0x38 0x60 0x9f 0xe5 0x6 0x0 0x50 0xe1 0x6 0x0 0x0 0x9a 0x0 0x10 0xe0 0xe3

When I disassemble the binary with arm-linux-gnueabihf-objdump -d azure-storage-azcopy then I see the following around the problematic address 0x133ec:

000133cc <runtime/internal/syscall.Syscall6>:
   133cc:       e59d7004        ldr     r7, [sp, #4]
   133d0:       e59d0008        ldr     r0, [sp, #8]
   133d4:       e59d100c        ldr     r1, [sp, #12]
   133d8:       e59d2010        ldr     r2, [sp, #16]
   133dc:       e59d3014        ldr     r3, [sp, #20]
   133e0:       e59d4018        ldr     r4, [sp, #24]
   133e4:       e59d501c        ldr     r5, [sp, #28]
   133e8:       ef000000        svc     0x00000000
   133ec:       e59f6038        ldr     r6, [pc, #56]   ; 1342c <runtime/internal/syscall.Syscall6+0x60>
   133f0:       e1500006        cmp     r0, r6
   133f4:       9a000006        bls     13414 <runtime/internal/syscall.Syscall6+0x48>

I’m not very fluent in ARM assembler, but this looks like valid code, and the byte sequence 0x38 0x60 0x9f 0xe5 does appear at address 133ec: in the assembler listing.

As this application is released by the project itself for other architectures and apparently is working without problem there, I wonder what I’m looking at. Can this be miscompilation, or does this look like a bug in the application or a library?