Hi Alex,
> > Exposing appropriate translation block flag allows plugins to
> > handle "memory only" blocks in appropriate way.
>
> We don't want to expose internal details to the plugin. It shouldn't
> need to care.
>
> Do you have a test case where you missed counting the execution of the
> instruction?
To speedup plugin execution time we want to shift processing logic to
block translation phase and keep execution callback light. Also moving
instrumentation at block level as opposite to instruction level, helps
to speedup up execution as well.
Given that, we prepare structures in translation callback. For example:
void handleBlockTranslation(qemu_plugin_id_t, qemu_plugin_tb* tblock)
{
BlockStats* s = new BlockStats();
s->init(tblock);
g_stats->append(s);
/* Then, insert execution callbacks and pass BlockStats as
userdata for quick data lookup in run time at:
1) basic block prologue:
qemu_plugin_register_vcpu_tb_exec_cb(tblock, cb, flags, s);
2) memory load/store:
qemu_plugin_register_vcpu_mem_cb(tblock, cb, flags,
mem_flags, s);
*/
}
Having artificial "mem only" block leads to allocation of new
BlockStats and memory access will be attributed to that block instead
of "original" one which is supposed to be executed. If we know that
block is "mem only" on translation phase, then memory callback is
implemented differently to find relevant BlockStats.
--
Mikhail
