some binaries crash with SIGILL on Zybo-Z7-20

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

I only played with basic utilities (sh, ksh, ps, top, ed, vi ..)
on Xilinx Zybo-Z7-20 board and they run fine but when I tried to
run afl tests, the afl-run binary crashed with SIGILL.
I then tried to debug it with gdb but it crashed with SIGILL too.

If my analysis is correct, it crashes in libc.so at a0580:

# objdump -d /usr/lib/libc.so.12.211 |grep -A 8 a0570:
   a0570:       e20cc07f        .word   0xe20cc07f
   a0574:       e92d4030        .word   0xe92d4030
   a0578:       e083310c        .word   0xe083310c
   a057c:       e3a0e001        .word   0xe3a0e001
   a0580:       e103409e        .word   0xe103409e     <--- HERE
   a0584:       ea000001        .word   0xea000001
   a0588:       e3550000        .word   0xe3550000
   a058c:       1afffffb        .word   0x1afffffb
   a0590:       e3540000        .word   0xe3540000

(objdump runs fine on my Zybo board).

This location is somewhere between _string_hash_func @ a03e4 and
atomic_cas_32_ni @ a05c4.

There is indeed an invalid instruction if I open libc.so on my
Intel notebook in radare2 tool:

[0x000a03e4]> s sym._string_hash_func
[0x000a03e4]> pd 125
...
       0x000a0568      a0c1a0e1       lsr ip, r0, 3
       0x000a056c      03308fe0       add r3, pc, r3
       0x000a0570      7fc00ce2       and ip, ip, 0x7f
       0x000a0574      30402de9       push {r4, r5, lr}
       0x000a0578      0c3183e0       add r3, r3, ip, lsl 2
       0x000a057c      01e0a0e3       mov lr, 1
  ..-> 0x000a0580      9e4003e1       invalid                     <--- HERE
 ,===< 0x000a0584      010000ea       b 0xa0590
 |::   0x000a0588      000055e3       cmp r5, 0
 |`==< 0x000a058c      fbffff1a       bne 0xa0580
 `---> 0x000a0590      000054e3       cmp r4, 0
   `=< 0x000a0594      f9ffff1a       bne 0xa0580
       0x000a0598      00e090e5       ldr lr, [r0]
       0x000a059c      1c309fe5       ldr r3, [0x000a05c0]        ; [0xa05c0:4]=0xe8880
       0x000a05a0      01005ee1       cmp lr, r1
       0x000a05a4      00208005       streq r2, [r0]
       0x000a05a8      03308fe0       add r3, pc, r3
       0x000a05ac      0020a0e3       mov r2, 0
       0x000a05b0      0e00a0e1       mov r0, lr
       0x000a05b4      0c2183e7       str r2, [r3, ip, lsl 2]
       0x000a05b8      3080bde8       pop {r4, r5, pc}
       0x000a05bc      bc880e00       strheq r8, [lr], -ip
       0x000a05c0      80880e00       andeq r8, lr, r0, lsl 17
       ;-- atomic_cas_32_ni:
       0x000a05c4      08309fe5       ldr r3, [0x000a05d4]        ; [0xa05d4:4]=0xdf754
       0x000a05c8      03308fe0       add r3, pc, r3
       0x000a05cc      003093e5       ldr r3, [r3]
       0x000a05d0      13ff2fe1       bx r3
       0x000a05d4      54f70d00       andeq pc, sp, r4, asr r7

Control flow around this instruction is quite interesing and I see
the same pattern is repeated several times:

[0x000a03e4]> s sym._string_hash_func
[0x000a03e4]> pd 125 ~ invalid
       ..-> 0x000a0444      9e4003e1       invalid
       ..-> 0x000a04ac      9e4003e1       invalid
       ..-> 0x000a0514      912003e1       invalid
       ..-> 0x000a0580      9e4003e1       invalid


I compiled the toolchain from sources updated few days ago and
the release from sources updated yesterday.

	$ ./build.sh -Uj4 -m evbarm tools
	$ cvs up -dP
	$ ./build.sh -Uj4 -m evbarm release

-- 
Alex