Hey guys,
I'm running into an issue which appears as though pseudo instructions are
being reordered and causing their return values to be incorrect
(untimely). I've simplified the problem down to running the following code
in the simulated system (x86, single-core, O3CPU):
op_params_t call_params;
call_params.arg[0] = ptr;
call_params.return_value = 0;
m5_mal(&call_params);
printf("Return: %d\n", call_params.return_value);
The m5_mal call is just a couple x86 assembly instructions like the other
existing magic instructions. The simulator, when handling this magic
instruction, updates the return value by writing into the simulated
system's memory at the call_params.return_value address, and I can trace
that it's writing the correct value in the correct location.
Looking at an Exec trace suggests that the tick that the magic
instruction is being executed is actually after the instructions
surrounding it by almost 300 cycles...
-----------------------------------------------------------------
136195500: system.cpu T0 : 0x40cccf.0 : CALL_NEAR_I : limm t1, 0xc4c :
IntAlu : D=0x0000000000000c4c
136195500: system.cpu T0 : 0x40cccf.1 : CALL_NEAR_I : rdip t7,
%ctrl153, : IntAlu : D=0x000000000040ccd4
136195500: system.cpu T0 : 0x40cccf.2 : CALL_NEAR_I : st t7, SS:[rsp +
0xfffffffffffffff8] : MemWrite : D=0x000000000040ccd4 A=0x7fffffffebd8
136195500: system.cpu T0 : 0x40cccf.3 : CALL_NEAR_I : subi rsp, rsp,
0x8 : IntAlu : D=0x00007fffffffebd8
136195500: system.cpu T0 : 0x40cccf.4 : CALL_NEAR_I : wrip , t7, t1 :
IntAlu :
*136354000:* global: gem5 faked syscall: malloc(ptr = 6e7070) *<<<---------
THIS IS A DPRINTF IN MY FAKED SYSCALL*
136210000: system.cpu T0 : 0x40d920 : m5_mal :
IntAlu :
136210000: system.cpu T0 : 0x40d924.0 : RET_NEAR : ld t1, SS:[rsp] :
MemRead : D=0x000000000040ccd4 A=0x7fffffffebd8
136210000: system.cpu T0 : 0x40d924.1 : RET_NEAR : addi rsp, rsp, 0x8
: IntAlu : D=0x00007fffffffebe0
136210000: system.cpu T0 : 0x40d924.2 : RET_NEAR : wripi , t1, 0 :
IntAlu :
136212000: system.cpu T0 : 0x40ccd4.0 : JMP_I : rdip t1, %ctrl153, :
IntAlu : D=0x000000000040ccd6
136212000: system.cpu T0 : 0x40ccd4.1 : JMP_I : limm t2,
0xffffffffffffff9f : IntAlu : D=0xffffffffffffff9f
136212000: system.cpu T0 : 0x40ccd4.2 : JMP_I : wrip , t1, t2 :
IntAlu :
136214000: system.cpu T0 : 0x40cc75.0 : MOV_R_M : ld rax, DS:[rsp +
0x28] : MemRead : D=0x0000000000703b80 A=0x7fffffffec08
136214000: system.cpu T0 : 0x40cc7a.0 : MOV_R_M : ld rdi, DS:[rsp +
0x20] : MemRead : D=0x0000000000703b60 A=0x7fffffffec00
136216000: system.cpu T0 : 0x40cc7f.0 : MOV_R_M : ld ebx, DS:[rax] :
MemRead : D=0x0000000000000000 A=0x703b80
-----------------------------------------------------------------
This exact same simulated code works in numerous other parts of the
simulated application I'm running, so I'm totally baffled by this one.
I've tried a bunch of different ways of fixing this, including making
return_value a volatile variable in the op_params_t struct, and making
call_params volatile, but I still get the same result.
Has anyone encountered this issue before, or have any suggestions about
how I might fix it?
Thanks,
Joel
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
Dept. of Computer Science, University of Texas - Austin
http://www.cs.utexas.edu/~hestness
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
