As Joel mentioned, I think the best next step would be to turn on the Exec debug flag so you can see what the CPU is actually doing right around this point. You're also looking at the references as they return to the CPU; if you look at the requests on the issue side, you should be able to tell exactly which instructions are generating them.
Steve On Wed, Sep 17, 2014 at 12:24 PM, Scott Lerner via gem5-dev < [email protected]> wrote: > That is interesting with the gem5 symbol table. I am only running one > program through gem5 so I don't think this is the problem (hopefully). > > Joel, > Here is the code I have put to make sure I don't get the instruction > stream. This is the exact code so if you see anything wrong with pointers > or otherwise please let me know. This is in RubyPort.cc. > > void RubyPort::ruby_hit_callback(PacketPtr pkt) > { > ... > if(!pkt->req->isInstFetch() && in_user_mode && !Microcode_ROM){ > //Print out debug > } > ... > } > > The trace that I am looking at is rather large so I wasn't able to go back > to the same pthread_barrier_wait example. Here is a similar one in the same > trace though. > > 5200319347500: system.l1_cntrl3.sequencer: Ruby Hit Callback: Read, Thread > number=3, Pkt Address=0x3fb951c8,Pkt Size=8, Func=pthread_barrier_wait, > *PC=0x4020c0* > 5200319353500: system.l1_cntrl3.sequencer: Ruby Hit Callback: Write, Thread > number=3, Pkt Address=0x3efced10,Pkt Size=8, Func=pthread_barrier_wait, > *PC=0x4020c6* > 5200319359500: system.l1_cntrl3.sequencer: Ruby Hit Callback: Read, Thread > number=3, Pkt Address=0x3fffdff0,Pkt Size=8, Func=pthread_key_create, > PC=0x401d20 > > 00000000004016d0 <lu>: > ... > 4020bd: f6 c2 0f test $0xf,%dl > *4020c0*: 0f 85 f2 00 00 00 jne 4021b8 <lu+0xae8> > *4020c6*: 4c 39 f2 cmp %r14,%rdx > 4020c9: 0f 86 d9 00 00 00 jbe 4021a8 <lu+0xad8> > ... > 0000000000402740 <OneSolve>: > > So you can see from the two Ruby hit callbacks, the PCs match up to "jne" > and "cmp" both of which I wouldn't expect to send a request to memory. If > the code above is correct, then there shouldn't be any of the instruction > stream in the output trace. > > Scott > > On Wed, Sep 17, 2014 at 11:58 AM, Steve Reinhardt via gem5-dev < > [email protected]> wrote: > > > 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 > > > _______________________________________________ > 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
