[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] memory trace with qemu

From: Lluís
Subject: Re: [Qemu-devel] memory trace with qemu
Date: Mon, 26 Jul 2010 23:44:11 +0200
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.8 Emacs/24.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

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.


 "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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]