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 -- mailto:av1...@comtv.ru
