[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH] target/s390x: don't double ld_code() when reading instru
From: |
Alex Bennée |
Subject: |
Re: [RFC PATCH] target/s390x: don't double ld_code() when reading instructions |
Date: |
Tue, 12 Oct 2021 15:52:13 +0100 |
User-agent: |
mu4e 1.7.0; emacs 28.0.60 |
Richard Henderson <richard.henderson@linaro.org> 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 sequential loading so end up reporting a malformed 6 byte
>> instruction buffer.
>
> 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 could
extend the interface to include the current pc of the load and make the
appropriate adjustments. That said it's a bunch hoops to jump every
instruction when we could just as easily add an assert and fix up any
cases where we do. I guess it comes down to how prevalent double dipping
in the instruction stream is when constructing a translation?
What happens if the protection of the code area changes half way through
a translation? Could a mapping change in flight?
>
>
> r~
--
Alex Bennée