Actually I just noticed that the PC in the trace is 0x402088 but the jle is at 0x402083, so maybe it's not so mysterious....
Steve On Wed, Sep 17, 2014 at 8:12 AM, Joel Hestness via gem5-dev < [email protected]> wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
