Ok, this should be fixed now. It was a silly typo essentially. Gabe
On 04/14/12 20:42, Steve Reinhardt wrote: > I don't have a lot to add beyond my original email... as I said, I was > using tracediff with --debug-flags=All to track down a bug, and saw a > number of spurious differences on the machInst output from the DPRINTF line > I excerpted below. It wasn't on every instruction, but once I figured out > it had something to do with macroops vs microops I kind of gave up and just > started using --debug-flags=All,-Decode (since the bug I was working on > wasn't in the CPU). > > I think there's pretty clearly some uninitialized data involved, as when I > did see differences in the output, none of the fields necessarily even made > sense (for example, the opcode num bytes field often had bizarre values), > and it didn't even seem like I got the same garbage from run to run. > > This was in SE mode, and it happened pretty early on (like 3 or 4 > instructions in), so I'd guess that it could be reproduced just by > tracediffing two instances of any x86 program. > > Steve > > On Sat, Apr 14, 2012 at 5:14 PM, Gabe Black <[email protected]> wrote: > >> Sorry for not responding sooner. I meant to, but then I got pulled in a >> different direction. I don't think this explanation is correct. For >> microops that are from the microcode ROM with no corresponding macroop, >> they'd all have a dummy ExtMachInst but it should be well defined and >> deterministic. If they're from the microcode ROM but have a macroop (ie. >> if it's a really complicated macroop) then they'd have its ExtMachInst >> instead. What specific problems are you seeing? There may be a bad >> pointer or unintentionally uninitialized data involved. >> >> Gabe >> >> On 04/14/12 16:18, Steve Reinhardt wrote: >>> So the issue is when you have a microop that's not part of a macroop? >> It's >>> understandable how that could be an issue. >>> >>> Nevertheless, (1) it's misleading to be printing dummy machInst >> information >>> and (2) worse yet, IMO, since the dummy information is apparently random, >>> it's leading to spurious differences in tracediff. >>> >>> Is there an easy way to identify when the machInst is bogus so we can >>> suppress printing it in the DPRINTF? >>> >>> Steve >>> >>> On Sat, Apr 14, 2012 at 3:08 PM, Nilay Vaish <[email protected]> wrote: >>> >>>> After reading decoder.cc, it seems that in case of execution being >> inside >>>> microcode rom, you can get some dummy value (defined in x86_traits.hh) >> for >>>> machInst. Otherwise you should get correct value for machInst. >>>> >>>> -- >>>> Nilay >>>> >>>> >>>> On Thu, 12 Apr 2012, Steve Reinhardt wrote: >>>> >>>> I'm running into some problems where I'm tracediffing two x86 runs and >>>>> getting some seemingly spurious differences in the decode output. >>>>> >>>>> The key question I have is: what is the meaning of the machInst field >> of a >>>>> micro op? >>>>> >>>>> The problem seems to be in the code below (from >>>>> http://repo.gem5.org/gem5/**file/d062cc7a8bdf/src/cpu/** >>>>> simple/base.cc#l403< >> http://repo.gem5.org/gem5/file/d062cc7a8bdf/src/cpu/simple/base.cc#l403> >>>>> ). >>>>> Note that if we're executing a macroop, then curMacroStaticInst has the >>>>> correct machInst, but the DPRINTF at the bottom is printing the >> machInst >>>>> from the microop (via curStaticInst), which appears in at least some >> cases >>>>> to be garbage. >>>>> >>>>> Am I diagnosing this properly? Any ideas on a fix? >>>>> >>>>> Steve >>>>> >>>>> >>>>> >>>>> //If we decoded an instruction and it's microcoded, start pulling >>>>> //out micro ops >>>>> if (instPtr && instPtr->isMacroop()) { >>>>> curMacroStaticInst = instPtr; >>>>> curStaticInst = >>>>> curMacroStaticInst->**fetchMicroop(pcState.microPC()**); >>>>> } else { >>>>> curStaticInst = instPtr; >>>>> } >>>>> } else { >>>>> //Read the next micro op from the macro op >>>>> curStaticInst = curMacroStaticInst->** >>>>> fetchMicroop(pcState.microPC()**); >>>>> } >>>>> >>>>> //If we decoded an instruction this "tick", record information about >> it. >>>>> if(curStaticInst) >>>>> { >>>>> #if TRACING_ON >>>>> traceData = tracer->getInstRecord(curTick(**), tc, >>>>> curStaticInst, thread->pcState(), curMacroStaticInst); >>>>> >>>>> DPRINTF(Decode,"Decode: Decoded %s instruction: 0x%x\n", >>>>> curStaticInst->getName(), curStaticInst->machInst); >>>>> #endif // TRACING_ON >>>>> } >>>>> ______________________________**_________________ >>>>> gem5-dev mailing list >>>>> [email protected] >>>>> http://m5sim.org/mailman/**listinfo/gem5-dev< >> http://m5sim.org/mailman/listinfo/gem5-dev> >>>>> ______________________________**_________________ >>>> gem5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/**listinfo/gem5-dev< >> http://m5sim.org/mailman/listinfo/gem5-dev> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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
