On Mon, Jul 26, 2010 at 8:16 PM, malc <av1...@comtv.ru> wrote: > On Mon, 26 Jul 2010, Eliot Moss wrote: > >> On 7/26/2010 6:20 AM, Llu?s wrote: >> > Eduardo Cruz writes: >> > >> > > Thanks for your awnsers. Stean, after I find the right place to capture >> > > the >> > > reads and writes I'll definitely try your trace tool. >> > >> > > Until now, this is what i found: >> > >> > > I am using the x86-64 target, and I know that, for instance, lots of >> > > reads >> > > pass here: >> > >> > > target-i386/translate.c gen_op_ld_T1_A0() >> > >> > Ok, I've seen at least 3 people working on this lately. >> > >> > Some time ago I wrote a message proposing two sets of modifications for >> > qemu, in >> > order to allow the analysis of guest code (like feeding traces to an >> > architecture simulator). >> > >> > What I proposed is based on two different functionalities: >> > >> > 1) backdoor: a mechanism for the guest to communicate with qemu, such that >> > tracing can be started, stopped, etc. >> > >> > My current approach is to decode an instruction that is deemed invalid >> > by the >> > target ISA according to the manual. >> > >> > This is only implemented for x86 right now, but it is trivial to >> > implement on >> > other architectures as long as there are unused opcodes. >> > >> > 2) instrumentation: a set of generic macros that signal events that might >> > be >> > of >> > interest. >> >> Etc. >> >> In the context of another simulator, we developed a different >> technique, which would be quite general and might be of interest >> for QEMU. We communicate with the simulator via a "fake" *device*, >> mapped into user-mode memory using an mmap call. If someone >> devised and coded such a device, then it could be used from any >> guest. > > I'v done something similar a while ago: > http://repo.or.cz/w/qemu/malc.git/shortlog/refs/heads/wctpci
in this repo tree, which part is your new code? i looked at the git log, and tried to search your name, but none looks related. thanks, Jun
