Hi, so it means only 0.16% of instruction are for test application and rest for kernel and background work. Is not this quite unbalanced?
Thanks & Regards Sunil shah On Tue, Jan 11, 2011 at 1:24 PM, Furat Afram <[email protected]> wrote: > Hi > Since MARSS is a full system simulator it simulates both kernel and user > space instructions , the 0Xffffffff81391884 rips are a kernel instructions > . > -Furat > > On Tue, Jan 11, 2011 at 12:06 AM, sunil shah <[email protected]>wrote: > >> Hello Avadh, >> >> Thank you for the help. >> >> >> >> I want to get the virtual address trace of x86 instruction executed. >>>> >>> >>> >> By default Marss provides a way to generate an execution trace. In >>> 'ptlsim.h' file, un-comment the '#define TRACE_RIP' and recompile. This >>> will enable capturing trace of executed instructions in file >>> 'ptl_rip_trace'. Note: If you run for long time this fill will eat up all >>> hard-disk space. >>> >> >> Enabling the TRACE_RIP will produce rip of all the uop. One x86 >> instruction might be broken down into multiple uop. So, just to get only one >> commit rip per x86 instruction I tried to obtain the rip of committed >> instruction from *ReorderBufferEntry::commit() *instead of >> *ThreadContext:commit(). >> *I verified both will generate the same sequence of rip's expect with >> TRACE_RIP enable, it will have as many entry of a rip as number of uop for >> the x86 instruction. >> >>> >>> I tried using in *ReorderBufferEntry::commit()* function field, * >>>> uop.rip.rip* field is giving some address but the obtained address is >>>> not same at the virtual address of instruction which I obtained by using >>>> objdump to disassemble the executable I am running. >>>> >>>> That is interesting. At what point are you switching from emulation to >>> simulation? If you are using 'start_sim' tool then it takes about 1 million >>> instructions to complete and start the next process. >>> >> >> Yes, I am using start_sim to switch from emulation to simulation. >> >>> >>> Also take a look at this python script ( >>> https://github.com/downloads/avadhpatel/marss/trace_to_func.py) that >>> helps in mapping RIP address to function of your benchmark/application. >>> >> >> RIP address is matched against the virtual address's of function obtained >> by objdump of executable. But the rip obtained are not always in the range >> of virtual addresses of function obtained by objdump. For instance mostly >> virtual address are in the range of 0X40xxxx but rip obtained are quite >> high values like 0X00007fe91323c3b7 or 0Xffffffff81391884 or so. Only * >> 0.15%* of address are in small address range rest are all high address >> value. >> >> So this addresses belongs to which function or program? >> Why there is no matching rip value to the virtual address of executable.? >> I am not sure, is there any offset or some re-mapping of testbench >> application into PTLSim memory map to some specific memory region? >> >> I am trying to generate basic block trace. What I am aiming to obtain is >> all executed instruction virtual address. And offline/ online I will convert >> it to basic block trace. >> >> >> Sorry for such a long email. >> >> Thanks & Regards >> Sunil Shah >> >> >> >> >> >> >>> - Avadh >>> >>>> Any help will be highly appreciated. >>>> Thanks in anticipation >>>> >>>> Regards >>>> Sunil Shah >>>> School of Computing >>>> NUS >>>> Singapore >>>> >>>> >>>> _______________________________________________ >>>> http://www.marss86.org >>>> Marss86-Devel mailing list >>>> [email protected] >>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>> >>>> >>> >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
