Hi Boris, Have you had any luck with this? I’ve taken another look at the loader debug output and the exec trace, and I’m stumped. The data from the loader appears correct as far as addresses and sizes of segments go, and as I said the address gem5 tries to load from when it crashes contains a valid instruction in the assembly. I don’t have much knowledge of what’s going on here; do you have any pointers as to what I could try next?
Thanks, Alec Roelke From: Boris Shingarov Sent: Thursday, February 9, 2017 1:03 AM To: gem5 Developer List Cc: Alec Roelke Subject: Re: [gem5-dev] RISC-V: Unknown opcode 0x00 Hmmm... why does __libc_setup_tls evoke a kind of deja-vu feeling? I don't remember the details now, but there definitely was a time when I was trying to rebuild a MIPS hello example with a definite version of gcc toolchain (because nobody seemed to know which toolchain version was used for the the gem5-provided binary), and got stuck on the gem5 SE simulation segfaulting somewhere related to __libc_setup_tls. For some reason I thought this was due to underimplemented support for the TLS syscalls, but I gave up temporarily, planning to come back to the problem when I have more time/ideas, but got drowned in other priorities. Now that it's not just MIPS but RISC-V, suddenly the problem seems that much more exciting. I'll try going back to remember what exactly it was that I discovered on MIPS... -----"gem5-dev" <gem5-dev-boun...@gem5.org> wrote: ----- To: gem5 Developer List <gem5-dev@gem5.org> From: Alec Roelke Sent by: "gem5-dev" Date: 02/07/2017 11:20AM Subject: Re: [gem5-dev] RISC-V: Unknown opcode 0x00 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 _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev