Greetings,
I was able to successfully reproduce the error using a stand
alone micro-program (which I have attached) and the source code is listed
below. The program runs fine (doesn't do anything really) stand alone, but
crashes in gem5 with the same signature of a random ADD instruction
appearing after the PEXTRB instruction. Two things to note, in the
committed version of GEM5 PEXTRB is not implemented but it SHOULD still be
decoded properly. The program works fine if I change the PEXTRB instruction
to reference a register instead of memory, it appears the bug becomes an
issue when the destination is a memory operand. The instruction listed
below is a copy of what was in my original program. Furthermore, I tried
running it the with immediate byte != 0 and the program did NOT crash in
GEM5. Any help would be greatly appreciated!
// Trace Error
5269000: system.cpu + A0 T0 : @main+4 : push rax
5269000: system.cpu + A0 T0 : @main+4.0 : PUSH_R : st rax, SS:[rsp +
0xfffffffffffffff8] : MemWrite : D=0x000000000040105e A=0x7fffffffed68
flags=(IsInteger|IsMemRef|IsStore|IsMicroop|IsDelayedCommit|IsFirstMicroop)
5269500: system.cpu + A0 T0 : @main+4.1 : PUSH_R : subi rsp, rsp, 0x8
: IntAlu : D=0x00007fffffffed68 flags=(IsInteger|IsMicroop|IsLastMicroop)
5270000: system.cpu + A0 T0 : @main+5 : push rdx
5270000: system.cpu + A0 T0 : @main+5.0 : PUSH_R : st rdx, SS:[rsp +
0xfffffffffffffff8] : MemWrite : D=0x00007fffffffee68 A=0x7fffffffed60
flags=(IsInteger|IsMemRef|IsStore|IsMicroop|IsDelayedCommit|IsFirstMicroop)
5270500: system.cpu + A0 T0 : @main+5.1 : PUSH_R : subi rsp, rsp, 0x8
: IntAlu : D=0x00007fffffffed60 flags=(IsInteger|IsMicroop|IsLastMicroop)
5271500: system.cpu + A0 T0 : @main+6 : mov rdi, 0
5271500: system.cpu + A0 T0 : @main+6.0 : MOV_R_I : limm rdx, 0 :
IntAlu : D=0x0000000000000000
flags=(IsInteger|IsMicroop|IsLastMicroop|IsFirstMicroop)
5272000: system.cpu + A0 T0 : @main+13 : mov rax, rsp
5272000: system.cpu + A0 T0 : @main+13.0 : MOV_R_R : mov rax, rax, rsp
: IntAlu : D=0x00007fffffffed60
flags=(IsInteger|IsMicroop|IsLastMicroop|IsFirstMicroop)
5273000: system.cpu + A0 T0 : @main+16 : sub rax, 0xc
5273000: system.cpu + A0 T0 : @main+16.0 : SUB_R_I : limm t1, 0xc :
IntAlu : D=0x000000000000000c
flags=(IsInteger|IsMicroop|IsDelayedCommit|IsFirstMicroop)
5273500: system.cpu + A0 T0 : @main+16.1 : SUB_R_I : sub rax, rax, t1
: IntAlu : D=0x0000000000000000
flags=(IsInteger|IsCC|IsMicroop|IsLastMicroop)
5274000: system.cpu + A0 T0 : @main+20 : pextrb DS:[rax], ax, 0
5274000: system.cpu + A0 T0 : @main+20.0 : PEXTRB_M_XMM_I : limm t0w,
0x755745 : IntAlu : D=0x0000000000005745
flags=(IsInteger|IsMicroop|IsDelayedCommit|IsFirstMicroop)
5274500: system.cpu + A0 T0 : @main+20.1 : PEXTRB_M_XMM_I : st t0b,
DS:[rax] : MemWrite : D=0x0000000000000000 A=0x7fffffffed54
flags=(IsInteger|IsMemRef|IsStore|IsMicroop|IsLastMicroop)
5275500: system.cpu + A0 T0 : @main+24 : add r9b, DS:[rax + rax]
5275500: system.cpu + A0 T0 : @main+24.0 : ADD_R_M : ld t1b, DS:[rax +
rax] : MemRead : A=0xffffffffdaa8
flags=(IsInteger|IsMemRef|IsLoad|IsMicroop|IsDelayedCommit|IsFirstMicroop)
panic: Tried to read unmapped address 0xffffffffdaa8.
// Compile me with: g++ -static -msse4 sse_test.cpp
#include "smmintrin.h"
int main() {
asm(
"pushq %rax \n"
"pushq %rdx \n"
"movq $0x0, %rdx \n"
"movq %rsp, %rax \n"
"subq $0xc, %rax \n"
"pextrb $0x0,%xmm0, 0xc(%rdx,%rax,1) \n"
"pxor %xmm0, %xmm0 \n"
"popq %rdx \n"
"popq %rax \n"
);
return 0;
}
>
>Do you have a small test program that demonstrates the bug? If so, please
>send it to me.
>
>Gabe
>
>On Sat, Nov 8, 2014 at 10:00 AM, Ahmed Khawaja via gem5-dev <
>[email protected]> wrote:
>
> Greetings,
>
> I am trying to run an SSE-enabled program through GEM5 in SE mode
> and
> I get an error about "panic: Tried to read unmpapped address
> 0x130c1c0", I
> disassembled my program and ran gem5 with instruction tracing. The
> offending instruction does NOT appear in the disassembled code. The
> interesting thing to note is I added an implementation of the PEXTRB
> instruction and the offending instruction (which shouldn't) is
directly
> after the first PEXTRB instruction is executed (it only shows 1 being
> executed, though in the source code they only appear in sequences of 8
> PEXTRB instrucitons in a row). I am lead to believe this is an issue
> with
> the front end decoder, can anyone tell me if my diagnosis seems
correct
> and
> what level of confidence should I expect in the front end decoder for
> an
> instruction that was NOT implemented.
>
> Thank you,
>
> Ahmed Khawaja
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
