Richard Henderson writes:
> On 9/13/21 3:06 AM, Alex Bennée wrote:
>>> Also, existing strageness in insn_idx being incremented for non-insns?
>> It shouldn't be - it's just using the presence of the memory
>> instrumentation as a proxy for the start of a instruction and dealing
>> with the slig
On 9/13/21 7:06 AM, Alex Bennée wrote:
Hmm so we have a separate list for speedy access:
/* list to quickly access the injected ops */
QSIMPLEQ_HEAD(, TCGOp) plugin_ops;
I wonder if we should drop that and just scan QTAILQ_HEAD(, TCGOp) ops
so we can be properly aligned with the curre
On 9/13/21 3:06 AM, Alex Bennée wrote:
Also, existing strageness in insn_idx being incremented for non-insns?
It shouldn't be - it's just using the presence of the memory
instrumentation as a proxy for the start of a instruction and dealing
with the slightly different start of block boundary.
Richard Henderson writes:
> On 9/3/21 7:59 AM, Alex Bennée wrote:
>> Coverity doesn't know enough about how we have arranged our plugin TCG
>> ops to know we will always have incremented insn_idx before injecting
>> the callback. Let us assert it for the benefit of Coverity and protect
>> ourse
On 9/3/21 7:59 AM, Alex Bennée wrote:
Coverity doesn't know enough about how we have arranged our plugin TCG
ops to know we will always have incremented insn_idx before injecting
the callback. Let us assert it for the benefit of Coverity and protect
ourselves from accidentally breaking the assump
Coverity doesn't know enough about how we have arranged our plugin TCG
ops to know we will always have incremented insn_idx before injecting
the callback. Let us assert it for the benefit of Coverity and protect
ourselves from accidentally breaking the assumption and triggering
harder to grok error
