While we're on the topic, I'll just mention that there is a known bug with the gem5 symbol table: there's only one symbol table and it's a global variable, so if you have a multiprogrammed workload, you're only going to have the symbols for the last program loaded. The rest of the code doesn't really understand this, though, so it will happily use that symbol table for all of the loaded programs.
If you're not loading multiple binaries, though, it *should* work, AFAIK. Steve On Wed, Sep 17, 2014 at 8:56 AM, Steve Reinhardt <[email protected]> wrote: > 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
