1

I am currently trying to run a program compiled for arm64 on Gem5. I am using the sve/beta1 branch of Gem5, linux kernel 4.15 and the program makes use of glibc (it's statically linked). To run Gem5 I am using the following command:

./build/ARM/gem5.opt configs/example/arm/fs_bigLITTLE.py --arm-sve-vl=8 --cpu-type=atomic --big-cpus=2 --little-cpus=2 --kernel=/dist/m5/system/binaries/linux4_15 --dtb=/dist/m5/system/binaries/armv8_gem5_v1_big_little_2_2.dtb --disk=/dist/m5/system/disks/linaro-minimal-aarch64.img

I am successfully booting the linux distro and the binary starts as well. However, after a while, I get the following error message:

[13602.881469] Program_Binary[1059]: undefined instruction: pc=000000006e018621 [13602.881484] Code: d503201f d11b43ff a9007bfd 910003fd (d50320ff)

I am not completely sure which instruction is causing this but I assume it is the instruction (d11b43ff) which according to the ARM reference manual is a msr instruction. Anyone have an idea as to how I could resolve this issue?

user132792
  • 41
  • 4

2 Answers2

1

Applying the changes of commits 260b0fc, 33b311d, 6efe7e1 and fcc379d of the public/gem5 branch to the sve/beta1 branch fixed this issue for both FS and SE simulation.

user132792
  • 41
  • 4
0

In general, there is only one solution: to go and implement the missing instruction.

Newer gem5 actually prints the binary opcode of the unimplemented instruction on the error message, which you can then use a disassembler to determine which instruction it is: Using objdump for ARM architecture: Disassembling to ARM Before that you would just have to find the opcode with objdump based on the PC address first.

In this particular case, since you are on a branch, you should first produce a minimal (se.py if possible because easy) example that uses the instruction and see if it was fixed in master.

As mentioned at: How to compile and run an executable in gem5 syscall emulation mode with se.py? however there has been a MRS glibc pre-main fix in the pas few months at commit 260b0fc5381a47c681e7ead8e4f13aad45069665 which did not yet go into sve/beta1. Can you try to cherry pick it and see what happens?

Ciro Santilli
  • 3,693
  • 1
  • 18
  • 44
  • Alright so after a few more hours of trial & error I have solved this issue. Turns out this problem wasn't present in the public/gem5 repo. Applying the changes of commits 260b0fc, 33b311d, 6efe7e1 and fcc379d to the sve/beta1 branch fixed this issue. – user132792 Jun 26 '19 at 08:20
  • @user132792 awesome, thanks for sharing the full cherry pick list! – Ciro Santilli Jun 26 '19 at 08:58