Hey Jason,
Thank you for your response. May I ask how should I cope the monitoring facilities with the address mapping? The following monitoring code is currently what I am using: system.monitor = CommMonitor() system.monitor.trace = MemTraceProbe(trace_file = "cache_package.ptrc.gz", with_pc = True) system.monitor.stackdist = StackDistProbe(verify = True) system.cpu.dcache_port = system.monitor.slave system.monitor.master = system.cpu.dcache.cpu_side Sincerely, ________________________________ 发件人: Jason Lowe-Power <[email protected]> 发送时间: 2017年1月2日 7:51:45 收件人: ps4 lover; [email protected] 主题: Re: Understanding the memory address in the trace Hello, I believe your confusion is because the addressed in the binary are virtual addresses, but the address trace shows physical addresses. You may be able to modify the address trace code to print both the virtual and physical addresses (when the virtual is available). IIRC, you can use pkt->req->getVaddr(). However, this will cause a panic if there is no virtual address, so you should check that first. Jason On Mon, Dec 26, 2016 at 4:16 PM ps4 lover <[email protected]<mailto:[email protected]>> wrote: Hello List, I am using the monitor/listener utilities of gem5's system call simulation. I am working on x86 binaries. I have set the memory space as 4G in the configuration file. I set a monitor/listener between the CPU and the L1DCache. Currently, I found it is hard to interpret the recorded memory address in the dumped trace. Suppose I am monitoring the following memory access: movzbl 0x81aa1a0(%edx),%eax Since the base address of the above load operation is 0x81aa1a0, I expect that the recorded memory address in the trace should be larger or at least equal to 0x81aa1a0. However, all the recorded memory address is something like: r,1450420,1,3,5178814000<tel:(517)%20881-4000> r,1450404,1,3,5180762000 r,1450403,1,3,5182652000<tel:(518)%20265-2000> r,1450401,1,3,5186636000<tel:(518)%20663-6000> ..... As you can see, the recorded memory address (1450420; 1450404..) is quite small.. Another observation is that, when the offset of the above memory access changes, the recorded memory address would not change. I have did some experiments, by changing the register "edx" into different values. However, I have confirmed that the recorded memory address sequence during runtime stays the same. It seems that something obviously went wrong here... But I really have no idea what happened. Am I missed anything here?Any suggestion or advice would be appreciated. Thank you. -- Jason
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
