On Wed, Nov 28, 2018 at 12:50:23 +0000, Alex Bennée wrote: > Emilio G. Cota <c...@braap.org> writes: > > I just wrote some code to go over the list and add TB callbacks, > > which go right before the first insn_start Op. The code is hack-ish > > in that we first generate the TCG ops we need, which get added to > > the end of the ops list, and then we go over those and move them > > to where we want them to be (before insn_start, in this case). > > But it works and it's less of a hack than doing the whole 2nd pass. > > But we should be able to insert the ops directly in the right place. > That is the whole point of being a list right ;-)
Right, it's just hard sometimes to know exactly where to insert. > > Insn callbacks will be trivial to implement this way; memory > > callbacks should be harder because there are several qemu_ld/st > > opcodes, but it should be doable; > > I was thinking about this last night. I wonder if we need to tag the > memory tcg ops so we can find them afterwards during the insertion > phase - but maybe the opcode itself provides enough information. We should be able to extract the info from the memop argument, I think. > > last, memory instrumentation > > of helpers might actually be easier than with the 2 passes, because here > > we just have to look for a Call TCG op to know whether a guest > > instruction uses helpers, and if it does we can wrap the call > > with the helpers to generate the setting/resetting of > > CPUState.plugin_mem_cbs. > > So merging the two helper calls into one from the target code? Actually we don't need helpers to set/reset CPUState.plugin_mem_cbs; we do that in TCG directly. So here we could just add the "set" code right after "insn_start", and the "reset" code at the very end of the translation (right before tb_exit/goto_tb etc). The "reset" might still be dead code, but that is unavoidable because the helper might do a longjmp. But we can fix that by resetting the variable when returning from the jump. Thanks, E.