Re: [Qemu-devel] memory trace with qemu

[Eduardo Cruz]

> I define INSTR_MEM macro into a generation of a helper call, which will 
> receive
> the run-time computed address.

Could you share how did you do this?

> If you'd also like to track pthreads and the like, you'll need some sort of
> backdoor communication channel.

Yes, I need to distinguish between threads of the same process, but I
already solved this by hacking the linux context switcher procedure.

2010/7/26 Lluís <address@hidden>:
> Eduardo Cruz writes:
>
>> In the modification:
>>  Oh! BTW, my current prototype uses code like this on target-x86/translate.c:
>>>
>>>    #define tcg_gen_qemu_ld8u(arg, addr, mem_index)          \
>>>        do {                                                 \
>>>            INSTR_MEM(addr, 8);                              \
>>>            (tcg_gen_qemu_ld8u)(arg, addr, mem_index);       \
>>>        } while (0)
>
>> As far as I understand, at this point, the code is still beig
>> translated, so we still dont know at this point the virtual address,
>> because the address will be computed when the generated code executes.
>> Am I correct? or am I completely lost?
>
> I define INSTR_MEM macro into a generation of a helper call, which will 
> receive
> the run-time computed address.
>
>
>> I think qemu should support the memory trace, and I'll try to do it.
>> I've already managed to hack the linux kernel to make it easy to
>> obtain the pid of the current process running on the cpu. If we can
>> make qemu generate the trace, we can make it only record the memory
>> access of specific process. I already do this using simics, but it is
>> extremely slow.
>
> I have already done all this with bochs, and I'm trying to port it into qemu 
> for
> speed :)
>
> The trick is extremely easy, as long as you don't want to differentiate 
> between
> pthreads. You just have to track modifications of the cr3 in x86. In fact, I 
> was
> planning on providing a generic INSTR_ASPACE macro, that would signal a change
> of address space.
>
> If you'd also like to track pthreads and the like, you'll need some sort of
> backdoor communication channel.
>
>
> Right now I'm stuck trying to let the user define a directory from where a
> library will be compiled for each target, such that not only code helpers and
> the like can be defined, but the user will also be available to link any other
> piece of external software (e.g., I have a separate full-fledged conditional
> tracing infrastructure that I'd like to call from the instrumentation macros).
>
> Just let me finish the this bit of Makefile black magic and I'll push the
> repository into a public place.
>
> Lluis
>
>
> --
>  "And it's much the same thing with knowledge, for whenever you learn
>  something new, the whole world becomes that much richer."
>  -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
>  Tollbooth
>



-- 
Eduardo Henrique Molina da Cruz
MSc student
Parallel and Distributed Processing Group
Federal University of Rio Grande do Sul (UFRGS)