Endless illegal instructions when running elf executables
I am using the simple system example of Ibex to run a program with Verilator, the program is generated by a random instrucion generator.
A short example of assembly files look like this:
.section .text
.global _start
_start:
.word 0x73800093
.word 0xca600113
.word 0xff700193
.word 0x56a00213
.word 0xaea00293
.word 0xbab00313
.word 0x0b400393
.word 0xfe300413
.word 0xb4000493
.word 0x39a00513
I use riscv gnu toolchain to compile it with command:
riscv64-unknown-elf-gcc -march=rv32imac -mabi=ilp32 -nostdlib -nostartfiles -o test test.s
the disassembly looks as below, and it seems to be no problem:
test: file format elf32-littleriscv
Disassembly of section .text:
00010054 <_start>:
10054: 73800093 li ra,1848
10058: ca600113 li sp,-858
1005c: ff700193 li gp,-9
10060: 56a00213 li tp,1386
10064: aea00293 li t0,-1302
10068: bab00313 li t1,-1109
1006c: 0b400393 li t2,180
10070: fe300413 li s0,-29
10074: b4000493 li s1,-1216
10078: 39a00513 li a0,922
However, when I simulate the simple system example of Ibex with this elf using Verilator and command:
./build/lowrisc_ibex_ibex_simple_system_0/sim-verilator/Vibex_simple_system -t --meminit=ram,test
ibex seems to be not able to execute these instructions as all I've got is endless illegal instruction like this:
3249: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3255: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3261: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3267: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3273: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3279: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3285: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3291: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3297: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3303: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3309: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3315: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3321: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3327: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3333: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3339: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3345: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3351: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3357: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3363: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3369: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3375: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3381: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3387: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3393: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3399: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
3405: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
Can anybody help me as to point out at which step I am making a mistake?
I notice that the first PC that is reported is 0x00100000, but your code starts at _start, which has address 0x0010054. And the reported instruction contents are 0x464c457f, which don't match anything in the objdump.
Is the problem just that you've started at the wrong address?
0x464c457f, which don't match anything in the objdump.
0x464c457f is the ELF magic number, could the file have been loaded 'raw'?
Also shouldn't the code be at 0010xxxx but the disassembly seems to be 0001xxxx?
now the first instruction is at the address of 0x00100000 in objdump:
00100000 <_start>:
100000: 21600093 li ra,534
100004: 33a00113 li sp,826
100008: c7300193 li gp,-909
10000c: 8ad00213 li tp,-1875
100010: 10200293 li t0,258
100014: 6f200313 li t1,1778
100018: b9f00393 li t2,-1121
10001c: b2100413 li s0,-1247
100020: 1f500493 li s1,501
100024: 7e600513 li a0,2022
100028: 69100593 li a1,1681
10002c: f1d00613 li a2,-227
100030: a1500693 li a3,-1515
100034: a7f00713 li a4,-1409
100038: e3d00793 li a5,-451
instructions are still reported illegal but at a different address again:
Simulation running, end by pressing CTRL-c.
Tracing enabled.
Writing simulation traces to sim.fst
17: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
97: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
177: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
257: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
337: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
417: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
497: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
577: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
657: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
737: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
817: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
Actually the first illegal instruction is always reported at a different address if I run a different binary, although the start address of these binaries are all the same at 0x00100000
I'd suggest taking a look at the simulation trace that's coming out. Notice that the cycle counter in the first column is now going up by 80 each line (instead of just one). My guess is that Ibex thinks it's running 79 valid instructions in the gaps...
actually the boot address of ibex is not 0x100000 but 0x100080, we should start the program at that address.