Hi Everyone, Does anybody know anything about how gem5 reads binaries and why this problem might be happening? If full-system mode for RISC-V is to be supported in the future (and probably for multithreading in SE mode as well), this will probably need to be fixed.
Thanks, Alec Roelke On Mon, Jan 23, 2017 at 3:12 PM, Alec Roelke <ar...@virginia.edu> wrote: > Hello, > > I'm trying to get the riscv64-linux-gnu-* tools working on gem5 for RISC-V > since right now only the riscv64-unknown-elf-* tools are compatible and > those don't include a lot of Linux headers. > > The problem I am encountering is that after returning from a function I > assume is part of libc (the assembly label is __libc_setup_tls), the next > instruction it reads is always 0x00000000, which is undefined in RISC-V and > causes a panic. For example, when I compile the example "Hello, world" > program with riscv64-linux-gnu-gcc, using the -static and -static-libgcc > flags, here is a snippet of the end of the Exec trace: > > @__libc_setup_tls+456 : jalr zero, ra, 0 : IntAlu : > D=0x000000000002e2ec > @__libc_start_main+140 : unknown opcode 0x00 : No_OpClass : > > The value of ra (return address register, just like in MIPS) in the first > line is @__libc_start_main+140 (0x2ddc4), which it appears to correctly > jump to in the second line. According to the assembly I dumped from the > binary, that should be an actual instruction (lui a5, 0x12, which loads > 0x12 into the upper 32 bits of register a5), but gem5 seems to be reading > 0x00000000. > > Does anyone know what's going on? > > Thanks, > Alec Roelke > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
