Alex, Thanks for the additional information.
>> >> A key aspect of what you propose here, is that the memory may have >> changed during the write time, and when you read it, while what we >> propose guarantees to track every change correctly. >> >> It's not a bad thing, and both API are definitely complementary. When >> talking to Alex, he was keen to add a global read_memory API (like you >> propose), after we merge the first one. >> >> @Alex: any thought on this? > > I'd like to get the memory callback API merged first - mostly because > that is the API that will absolutely reflect what was loaded or stored > to a given memory location. For precise instrumentation that is the one > to use. > > However I agree the ability to read the state of memory outside of loads > and stores is useful especially for something like this. It's not > unreasonable to assume the memory state of arguments going into a > syscall isn't being messed with and it is easier to track pointers and > strings with a more general purpose API. > I agree, I considered the absolute load/store question and poked around the code a bit, but I didn't find what looked like a solid way to either: A) Ensure that all writes are flushed before the read happens (which sounds like a hefty performance penalty anyway) or B) Check whether there are outstanding writes and return an error It sounds like essentially use cases where that level of per-insn write granularity matters should utilize your upcoming API instead of this one, and I will add a call-out to the doc of this one to alert users of the potential pitfall. >>> qemu_plugin_register_vcpu_syscall_cb(id, vcpu_syscall); >>> qemu_plugin_register_vcpu_syscall_ret_cb(id, vcpu_syscall_ret); >>> qemu_plugin_register_atexit_cb(id, plugin_exit, NULL); > > There was someone on IRC looking to trace system calls in system mode > (by tracking the syscall instruction and reading the registers at the > time). I wonder if we could make this plugin do the right thing in both > modes? > Cool! I think this should be doable. -Rowan
