On Wed, Aug 15, 2012 at 4:57 AM, Prathmesh Kallurkar <prathmesh.kallur...@gmail.com> wrote: > 1. Did you get the guest physical address for the load/store instructions? > No, I am getting the guest virtual address for the load and store > instructions. > > >> >> 2. The code you pasted seems translated code. The number of input code >> could be smaller than this. So don't you think we should trap the >> input code, instead of the translated code? > > > I am trapping the guest code and NOT the translated code. For this I am > transferring the guest instruction bytes (using ldub_code) to a remote > disassembler and then inspecting the instruction. > >> >> > cmp ecx, [r12+0x4] >> > mov r10b, [r13+0x0] >> > mov byte [rax+0xf0000], 0x0 >> > mov byte [rax+rdx], 0x0 > > > The above instructions are instructions of a i386 guest system.
In the above code, can your disassembler get the value of the register? For example what is in dcx or r12? >> >> >> 3. Suppose that I have a tb block which has only one instruction to be >> translated >> mov 0x4(%esp),%edx >> I tried to calculate the guest physical address of 0x4(%esp) in >> the above in the function of disas_insns(...), is this possible? Or do >> you have any other solutions? > > > Sorry but seems I have not considered this case. See, I am just trapping the > calls to tcg_gen_qemu_ld/st and then checking my coverage by inspecting the > decoded instructions given by my disassembler. I flag an error when I > receive an instruction which was supposed to contain a load/store > instruction but I could not trace one. I will definitely see what I get for > mov 0x4(%esp),%edx > I tried to trace the guest virtual address of the memory access in this load instruction. However, the value of 0x4(%esp) seems to be resolved at the translated code, instead of the disassemble step. Can your diassembler resolve the value of 0x4(%esp)? > > -- > Regards, > Prathmesh Kallurkar
