Hey Majid and Jason,
Thank you so much for these detailed information. I learned a lot from them:) Now I am able to boot the full-system simulation and record the cache status. I really appreciate your help! While the current system works well on all the program binaries compiled from C program, I am trapped in executing one C++ test case in the full-system simulation mode... My current configuration is: Kernel 3.2.0 + Ubuntu 12.04.4 64-bit. I compiled the kernel with the gem5 provided configuration file: linux-2.6.28.4. When running the binary code, it throws an exception: pure virtual method called terminate called without an active exception Aborted Of course, this more seems like a source code-level bug, calling virtual function inside the constructor or something. However, I tried the same code on various physical machines (including a Ubuntu 12.04 64-bit with kernel version 3.2.0 and a Ubuntu 12.04 64-bit with kernel version 3.8.0-44), and all of them work well. Besides, although debugging on the simulated platform is too slow, I use strace to dump the system call sequence when executing the static-linked C++ binary code and checked the constructor/destructor functions around the call sites; I haven't seen any suspicious code pieces so far. I am starting to think, maybe some configurations of the simulated platform lead to this issue.. Is there anything chance that any of this problem looks familiar to you guys..? If so, could you shed some lights on it? Thank you in advance! Sincerely, Shuai On Thu, Jan 5, 2017 at 8:40 AM, Jason Lowe-Power <[email protected]> wrote: > Hi Shuai, > > By default, se/fs.py use the atomic CPU, which performs atomic memory > accesses. This CPU/memory mode is used to fast-forward the simulation, and > does not accurately perform timing operations. All of the memory > requests/responses flow through the "atomic" functions (recvAtomic). You > should specify the CPU type on the command line to use timing mode (e.g., > --cpu-type=timing or --cpu-type=detailed). > > Cheers, > Jason > > On Wed, Jan 4, 2017 at 9:52 AM Shuai Wang <[email protected]> wrote: > >> Sorry, what I mean is function "recvTimingReq", not function " >> schedTimingResp"... >> >> On Wed, Jan 4, 2017 at 10:23 AM, Shuai Wang <[email protected]> >> wrote: >> >> Besides, while my instrumented code in the "schedTimingResp" function >> works well when leveraging the system call mode, I find the "schedTimingResp" >> function is never executed in the full-system simulation mode. Am I missed >> anything here? >> >> This is the command I use: >> >> ./build/X86/gem5.opt --debug-flags=CacheDebug >> --debug-file=cacheDebug.out.gz configs/example/fs.py >> --disk-image=/home/test/work/x86_full_system/disks/linux-x86.img >> --kernel=/home/test/work/x86_full_system/binaries/x86_64-vmlinux-3.2.1 >> --caches >> >> By inserting some printf at the beginning of function "schedTimingResp >> ", I am pretty sure this function is never invoked... >> >> On Tue, Jan 3, 2017 at 11:13 PM, Shuai Wang <[email protected]> >> wrote: >> >> Hi Majid, >> >> Thank you so much for your detailed information. I strongly appreciate >> that. >> >> I tried to update the code as you said, and it works fine to dump the >> information in the C++ code. However, I am still confused to interpret the >> "cache state" information at this step. Could you please take a look at the >> following questions and shed some lights on it? Thank you! >> >> The first question is that I can never observe a "cache miss": >> >> So what I am basically doing right now, as you suggested, is to check the >> conditions in the context of each "cpuSidePort->schedTimingResp" to >> decide whether the current memory addressing leads to a hit or miss. >> However, after running multiple test cases (including some small binaries >> and mediam size GNU Coreutils binaries), all I can find is the "hit" >> (schedTimingResp >> at line 742 of the cache.cc) and schedTimingResp at line 1454 of the >> cache.cc. Basically I cannot find any "miss" (schedTimingResp at line >> 801 of the cache.cc). Am I missed anything here? >> >> The second question is still about the interpretation of the cache state: >> >> If I understood correctly, given a N-bit memory address, it is >> dissected into the following three parts in a memory access: >> >> [image: Inline image 2] >> >> The "set index" is used to locate the cache set in which the data may be >> stored, and the tag is used to confirm that the data currently indeed >> presents in one of the cache lines in that cache set. In other words, I >> understand that the "cache state" (hit; miss; etc.) should be associated >> with each cache set regarding every memory addressing. >> >> Given the above context, I would like to confirm that the captured >> "hit/miss" surely represents the cache state of the accessed cache set. Or >> it is actually something towards the cache lines? >> >> Am I clear on this? Any suggestion and advice would be appreciated! Thank >> you! >> Sincerely, >> Shuai >> >> >> >> On Tue, Jan 3, 2017 at 3:12 PM, Majid Namaki Shoushtari <[email protected] >> > wrote: >> >> Hi Shuai, >> >> I don't think Jason meant that you need to add a function to Caches.py. >> You will need to add something to the C++ class (src/mem/cache/cache.hh/cc). >> >> I'm not sure what kind of information you need to dump, but basically all >> of the incoming requests from CPU are received here: >> "Cache::CpuSidePort::recvTimingReq(PacketPtr >> pkt)" >> and all of the responses to CPU are happening anywhere there is a call >> to: "cpuSidePort->schedTimingResp". There is currently four places that >> responses to CPU are scheduled. If you read the code, it's relatively easy >> to figure out which call site covers what condition (hit, miss, uncacheable >> access, etc). >> >> If you need to dump this information for one (some) specific cache(s) >> only, one way of doing it is to pass a boolean variable and make it >> conditional based on the value of that variable. For that you will need to >> add the variable to Caches.py and possibly CacheConfig.py. >> >> Cheers, >> Majid >> >> >> On Tue, Jan 3, 2017 at 8:21 AM, Shuai Wang <[email protected]> >> wrote: >> >> Dear Jason, >> >> Thank you so much for your reply. Could you please elaborate more on how >> to "implement a function in Caches.py to dump the data"? As far as I can >> see, there are only some cache parameters defined in this scripts.. I >> really have no idea how should I bridge the code there with the runtime >> cache state (my focus is the L1 D Cache)... >> >> I am not a system person and I am sincerely sorry if it is actually quite >> obvious... Thank you so much in advance! >> >> Sincerely, >> Shuai >> >> On Mon, Jan 2, 2017 at 11:01 AM, Jason Lowe-Power <[email protected]> >> wrote: >> >> Hi Shuai, >> >> There is currently nothing built into gem5 to dump the cache state >> (unless you're using Ruby in which case you can look at the code to take a >> checkpoint in the RubySystem class and the CacheTrace class). However, it >> should be pretty simple to dump the data in the classic caches. You would >> need to get a pointer to all of the caches, then add a function to the >> Cache class that dumps the data. You may be able to leverage the DDUMP >> macro which formats data in a reasonable way. Or, if you're only going to >> be using code to consume the output, you can look into the protobuf support >> in gem5 for dumping/consuming data. >> >> Cheers, >> Jason >> >> On Thu, Dec 29, 2016 at 10:38 PM Shuai Wang <[email protected]> >> wrote: >> >> Dear list, >> >> >> I am using the full-system simulation of gem5 to analyze the cache access >> of some x86 binary code. I have been able to add a monitor between the CPU >> and the L1 data cache to track all the cache access when executing the >> binary code on the simulated OS. >> >> Currently, I am thinking to go one step further and dump the cache state >> during the execution of the binary code. After a quick search online, I am >> unable to find some useful information, and I am wondering if it is >> actually possible to do so..? >> >> Could anyone provide some pointers regarding this task? Thank you in >> advance! >> >> Sincerely, >> Shuai >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> -- >> >> Jason >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> >> -- >> Majid Namaki Shoushtari >> PhD Candidate >> Department of Computer Science >> University of California, Irvine >> Irvine, CA 92697 >> [email protected] >> http://www.ics.uci.edu/~anamakis >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> >> -- > > Jason >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
