Aaron Lindsay <aa...@os.amperecomputing.com> writes:
> On Nov 15 22:36, Alex Bennée wrote: >> Aaron Lindsay <aa...@os.amperecomputing.com> writes: >> > I believe the code *should* always reset `cpu->plugin_mem_cbs` to NULL at >> > the >> > end of an instruction/TB's execution, so its not exactly clear to me how >> > this >> > is occurring. However, I suspect it may be relevant that we are calling >> > `free_dyn_cb_arr()` because my plugin called `qemu_plugin_reset()`. >> >> Hmm I'm going to have to remind myself about how this bit works. > > When is it expected that cpu->plugin_mem_cbs is reset to NULL if it is > set for an instruction? Is it guaranteed it is reset by the end of the > tb? It should be by the end of the instruction. See inject_mem_disable_helper() which inserts TCG code to disable the helpers. We also have plugin_gen_disable_mem_helpers() which should catch every exit out of a block (exit_tb, goto_tb, goto_ptr). That is why qemu_plugin_disable_mem_helpers() is only really concerned about when we longjmp out of the loop. > If I were to put an assertion in cpu_tb_exec() just after the call > to tcg_qemu_tb_exec(), should cpu->plugin_mem_cbs always be NULL > there? Yes I think so. > In my debugging, I *think* I'm seeing a tb set cpu->plugin_mem_cbs > for an instruction, and then not reset it to NULL. I'm wondering if its > getting optimized away or something, but want to make sure I've got my > assumptions correct about how this is intended to be working. We are expecting some stuff to dead code away (but hopefully in pairs). We don't know ahead of the instruction decode if it will be a memory instruction so opportunistically insert our empty helper calls. If no memory access is done those ops should be gone. This is all done to avoid doing a 2 pass translate. Richard, Have I got that right? I think thats how I remember the TCG code working. > > Thanks! > > -Aaron -- Alex Bennée
