Re: [gem5-dev] RISC-V: Unknown opcode 0x00

2017-02-13 Thread ar4jc 
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 0x, 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=0x0002e2ec
>  @__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
> 0x.
>
> 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

Re: [gem5-dev] RISC-V: Unknown opcode 0x00

2017-02-08 Thread Boris Shingarov 
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 0x, 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=0x0002e2ec
>  @__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
> 0x.
>
> 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

Re: [gem5-dev] RISC-V: Unknown opcode 0x00

2017-02-07 Thread Alec Roelke 
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  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 0x, 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=0x0002e2ec
>  @__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
> 0x.
>
> 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] RISC-V: Unknown opcode 0x00

2017-01-23 Thread Alec Roelke 
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 0x, 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=0x0002e2ec
 @__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
0x.

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