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
