What changeset are you running with?
On Sun, March 3, 2013 4:08 pm, Joel Hestness wrote: > ::maybe a question for Gabe Black:: > > Hey guys, > When running x86 with the O3CPU, I'm running into a bug where the PC > appears to be advancing 5 bytes on a nop instruction that is only 4 bytes > long. From what I can tell, the Decoder offset variable should be 0 when > Decoder::decode() calls updateNPC(), but instead, it has been updated to > 1, > because the decoder thinks a second byte of immediate should be read. > > I've included assembly code from the binary and an Exec trace of the > instruction stream here (longer trace with Decode and Fetch flags > attached): > > ---------------------ASSEMBLY---------------------- > 40165f: 48 85 db test %rbx,%rbx > 401662: 74 5a je 4016be <exit+0x6e> > 401664: 0f 1f 40 00 nopl 0x0(%rax) > *<<<<<<<<<--------- > GOES OFF THE RAILS ON THIS INST* > 401668: 48 8b 43 08 mov 0x8(%rbx),%rax > 40166c: 48 89 c2 mov %rax,%rdx > 40166f: 48 c1 e2 05 shl $0x5,%rdx > 401673: 48 85 c0 test %rax,%rax > 401676: 48 8d 4c 1a f0 lea -0x10(%rdx,%rbx,1),%rcx > ---------------------ASSEMBLY---------------------- > > ---------------------TRACE---------------------- > 5051916399000: system.switch_cpus0 T0 : 0x40165f.0 : TEST_R_R : and > t0, rbx, rbx : IntAlu : D=0x0000000000000000 > 5051916399000: system.switch_cpus0 T0 : 0x401662.0 : JZ_I : rdip t1b, > %ctrl153, : IntAlu : D=0x0000000000401664 > 5051916399000: system.switch_cpus0 T0 : 0x401662.1 : JZ_I : limm t2b, > 0x5a : IntAlu : D=0x000000000000005a > 5051916399000: system.switch_cpus0 T0 : 0x401662.2 : JZ_I : wrip , > t1b, t2b : IntAlu : > 5051916399000: system.switch_cpus0 T0 : 0x401664.0 : HINT_NOP : fault > No Fault : No_OpClass : *<<<<<<<<<--------- PC ADVANCES 1 BYTE TOO > FAR FROM HERE* > 5051916399000: system.switch_cpus0 T0 : 0x401669.0 : MOV_R_M : ld al, > DS:[bl + 0x8] : MemRead : A=0x8 > 5051916415500: system.switch_cpus0 T0 : 0x401669.32890 : Microcode_ROM : > slli t4, t1, 0x4 : IntAlu : D=0x00000000000000e0 > 5051916415500: system.switch_cpus0 T0 : 0x401669.32891 : Microcode_ROM : > ld t2, IDTR:[t4 + 0x8] : MemRead : D=0x00000000ffffffff > A=0xffffffff8092c0e8 > 5051916608500: system.switch_cpus0 T0 : 0x401669.32892 : Microcode_ROM : > ld t4, IDTR:[t4] : MemRead : D=0x80618e0000107980 A=0xffffffff8092c0e0 > 5051916608500: system.switch_cpus0 T0 : 0x401669.32893 : Microcode_ROM : > chks , t4b, 0x3 : IntAlu : > 5051916608500: system.switch_cpus0 T0 : 0x401669.32894 : Microcode_ROM : > srli t10, t4, 0x10 : IntAlu : D=0x000080618e000010 > 5051916608500: system.switch_cpus0 T0 : 0x401669.32895 : Microcode_ROM : > andi t5, t10, 0xf8 : IntAlu : D=0x0000000000000010 > 5051916608500: system.switch_cpus0 T0 : 0x401669.32896 : Microcode_ROM : > andi t0w, t10w, 0x4 : IntAlu : D=0x0000000000000020 > ---------------------TRACE---------------------- > > This happens shortly after a CPU switch from TimingSimpleCPU to O3CPU, > so > the nop isn't in the decode cache prior to this (TimingSimpleCPU executes > correctly through this code also). The branch prediction of not taken is > correct on the je. I see that there were a handful of changes to the way > the offset variable is handled and checking when an instruction decode is > complete in changeset 9376:270c9a75e91f ( > http://repo.gem5.org/gem5/rev/270c9a75e91f), and I hadn't run into this > bug > when running with an older changeset (9162). Is it possible this is > related to those changes? Any idea what's wrong? > > Thanks, > Joel > > > P.S. Should I submit this as a bug to Flyspray? > > -- > Joel Hestness > PhD Student, Computer Architecture > Dept. of Computer Science, University of Wisconsin - Madison > http://www.cs.utexas.edu/~hestness > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
