On 10/12/21 7:52 AM, Alex Bennée wrote:
I think the plugin stuff could be more clever, knowing where the read
occurs within the sequence. Otherwise, we should simplify the
interface so that it is not possible to make this mistake.
It's plugin_insn_append which is doing the tracking here so we
Richard Henderson writes:
> On 10/12/21 2:31 AM, Alex Bennée wrote:
>> For the 4 byte instruction case we started doing an ld_code2 and then
>> reloaded the data with ld_code4 once it was identified as a 4 byte op.
>> This is confusing for the plugin hooks which are expecting to see
>> simple s
On 10/12/21 2:31 AM, Alex Bennée wrote:
-case 6:
-insn = (insn << 48) | (ld_code4(env, s, pc + 2) << 16);
+ case 6:
+ insn = deposit64(insn, 16, 32, ld_code4(env, s, pc + 2));
break;
Looks like some of indentation error?
Otherwise,
Reviewed-
On 10/12/21 2:31 AM, Alex Bennée wrote:
For the 4 byte instruction case we started doing an ld_code2 and then
reloaded the data with ld_code4 once it was identified as a 4 byte op.
This is confusing for the plugin hooks which are expecting to see
simple sequential loading so end up reporting a ma
For the 4 byte instruction case we started doing an ld_code2 and then
reloaded the data with ld_code4 once it was identified as a 4 byte op.
This is confusing for the plugin hooks which are expecting to see
simple sequential loading so end up reporting a malformed 6 byte
instruction buffer. While w
