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
