How about checking the response latencies of LDR/STR requests at CPU side, the longest response latency indicates memory accesses, without keeping track of addresses that are sent to the DRAM controller.
Normally, if I understand what you are trying to do correctly, you need to keep track of the address range of the stack [stack_pointer, stack_top], the address range of the stack is virtual. And you need to keep track of the addresses going into the memory, which are physical. You need to convert the physical addresses to virtual addresses, and see whether the addresses fall inside the stack range. Hope this helps? Jack Jack Harvard On Mon, Jan 26, 2015 at 4:25 PM, Leonardo Ecco via gem5-users <[email protected]> wrote: > I'm currently struggling to trace accesses to the software stack that > are not found in the cache (and, therefore, must be forwarded to the > DRAM). > By stack I mean the portion of memory dedicated to the stack (as in > the figure below). > > --------------- > | Stack | > | || | => Portion of memory that I'd like to keep track of. > | \/ | > | | > | | > | /\ | > | || | > | Heap | > --------------- > | bss | > --------------- > | data | > --------------- > | text | > --------------- > > > Does anyone envision a way to do this without keeping track of the > addresses that are sent to the DRAM controller? > Is this something that a communication monitor could keep track of? > _______________________________________________ > 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
