Re: [m5sim-users] Debugging bogus memory access

[Kevin Lim]

James Srinivasan wrote: What did you modify within M5? One of those modifications may be causing the CPU to go down the wrong path and try to access a bad address. I've added some more stats to the caches so it *shouldn't* be causing any functional differences... Does the error happen with the same configuration on an unmodified M5 then? Unfortunately the CPU doesn't have many debugging statements, so it may be a bit difficult to track down if you think the error is in the CPU itself. You might want to start by turning on some trace flags to see if the instructions executed at least look correct. You can do this by using --Trace.flags="InstExec". You can also use "Bus" and "Cache" as parameters to see if the memory stream looks correct as well. If you're able to find something wrong, you can narrow down the cycles you need to look at and possibly step through the CPU with GDB or add some debugging statements yourself. There's also an option for --Trace.start=<cycle>, which helps limit the amount of output you get. Unfortunately the bogus memory operation only seems to happen several hundred million cycles in so it's a long wait! I've had plenty of those as well :) If you're running in non-full system mode, then you might be able to use the tracediff utility to compare the output of two configurations. It's in the util directory; just open it up and it has instructions inside of it (it's a short script). Generally I run this with the common option of "--Trace.flags="InstExec" -P"root.exetrace=ExecutionTrace(print_cycle=False)" " in order to compare output of two configurations. Beware that if you have interrupts or results dependent on your configuration (such as the Rpcc instruction), this may work only if your error is early on. Thanks, I am running in SE mode. I'll take a look at dumping and diffing some traces. I was afraid it might come to this. Current theory is that the case that works hits in the LSQ whereas the one which doesn't work misses but it's just a stab in the dark. The benefit of using tracediff is you don't have gigantic trace files lying around as it generates the diff while the program is running.  If it's several hundred million cycles in, then you'll definitely want to use tracediff.  As far as your theory, looking briefly at the code it is a possiblity, though that would indicate that the CPU model allows bad accesses to go off to memory in the case of stores.  I think something else in the memory system would panic if that was the case (then again it might not).  Let us know what you find, as it might be an outstanding bug in the CPU model. Thanks again, James ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ m5sim-users mailing list m5sim-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/m5sim-users