This particular run is with 9477:d0aacc54cee9. I can try updating to the latest head, but I didn't see any more recent changes to the affected code that suggests this has been addressed.
Thanks, Joel On Sun, Mar 3, 2013 at 6:41 PM, Nilay <[email protected]> wrote: > 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 > -- 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
