Hi, Nate, thanks for your reply,the mismatch between req->getPaddr and req->paddr makes me diffident to pick an address range for my own structure.
Do you mean that it's the problem of gdb, the M5 still works correctly? Can I just change the req->getPaddr() to req->paddr ? I guess then the function will work as I expect. Thank you ! > Message: 4 > Date: Tue, 24 Feb 2009 21:20:25 -0800 > From: nathan binkert <[email protected]> > Subject: Re: [m5-users] uncached access of M5 > To: M5 users mailing list <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > > Thanks for your replay, Ali. I read the file in src/arch/alpha/tlb*.? The > > only function that related to uncache access seems the > checkCacheability() > > that mark the uncache flag of a request. > This is correct. If you pick a memory range that will match for this > function (or modify the function), you'll get what you want. > > > > I used gdb to get to this function, but the req->getPaddr confused me. > This > > function is simply to return the paddr field of a request, but I got > this, > > > > (gdb) p req->getPaddr() > > $7 = 608138816306466688 > > (gdb) p req->paddr > > $8 = 36200 > > > > The two paddr above seems not mathc. What's the reason? Further, if I > want > > add an small structure in o3 cpu and get it accessed in uncached mode, > which > > part of the cpu is the best to add ? I want this structure to be accessed > by > > application. Thanks ! > This is hard to explain. gdb doesn't always get things right when you > access things in functions and it depends a lot on OS, library > versions, and gdb version as to whether it works or not. You're best > off accessing the member variable directly when able. Things to look > at are: what does gdb think the type of req is? Are you optimized? Is > there a reference involved. > > In the case of checkCacheablility, there is a reference involved which > I'd say is certainly causing the strange behavior. In this case (and > in most of the cases of RequestPtr &), I think this is actually a bug > since I don't think we need to modify the pointer. I believe that > Gabe is fixing this in a series of patches that he has, but in > general, we should fix other improper cases of this. > > Nate >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
