Hi Scott, You could run an Exec trace around the time when you are seeing strange PCs. Just add 'Exec' (sans quotes) to your --debug-flag= command line. I'd recommend only collecting maybe a million ticks before the problematic PC (or the trace gets very long), and you can do this with --debug-start= 5228734114000.
I've never seen an exec trace show incorrect PCs, so it should be reliable. If the Exec PCs do actually differ from your memory request trace, then something is definitely funky. Another thing to consider is that the read request you're seeing in the hit callback may be an instruction stream read rather than a data read that resulted from executing an instruction. I'm not sure how the fetch units set packet addresses and PCs, so it may be worth some digging in the code to check that (Also note that if the Exec trace doesn't show a memory request instruction executing near the offending PC, this may be an indicator that the request is for the instruction stream). Joel On Wed, Sep 17, 2014 at 9:31 AM, Scott Lerner via gem5-dev < [email protected]> wrote: > That is exactly why I was concerned. I tried to find the micro-ops for the > jmp instruction to see if there was some type of format that read or wrote > to memory, but I couldn't find anything. > > Scott > > On Wed, Sep 17, 2014 at 12:27 AM, Steve Reinhardt via gem5-dev < > [email protected]> wrote: > > > Tough to say... my gut feeling is that the numeric PC is more likely to > be > > correct, but on the other hand, the PC appears to map not only to a > > different function, but to an instruction that's not even a memory > access, > > which makes it odd that it is generating a request packet. > > > > Steve > > > > On Tue, Sep 16, 2014 at 11:41 AM, Scott Lerner via gem5-dev < > > [email protected]> wrote: > > > > > Hi all, > > > > > > I am trying to do some validation of gem5 by looking at the output > memory > > > traces and comparing them to the static-compiled binary. > > > > > > What I have seen is that in the memory trace there will be an output > line > > > like: > > > "5228735114000: system.l1_cntrl3.sequencer: Ruby Hit Callback: Read, > > Thread > > > number=3, Pkt Address=0x3ff250c0,Pkt Size=8, Func=pthread_barrier_wait, > > > PC=0x402088" > > > > > > But when looking at the dump of the binary, the PC 0x402088 maps to a > > > different function: > > > 00000000004016d0 <lu>: > > > ... > > > 402083: 0f 8e f4 00 00 00 jle 40217d <lu+0xaad> > > > ... > > > 0000000000402740 <OneSolve>: > > > > > > My question is should I trust the PC or the function name? Is there a > way > > > to verify that either one is correct? I am using the gem5 from February > > > last year. > > > > > > Thanks, > > > > > > Scott > > > Ph.D. candidate > > > Drexel University > > > _______________________________________________ > > > 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 > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
