Endless illegal instructions when running elf executables

[yulong-lan]

Endless illegal instructions when running elf executables

[rswarbrick]

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?

[mdhayter]

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?

[yulong-lan]

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

[rswarbrick]

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...