Re: Detecting Faulting Instructions From Plugins

[Alex Bennée]

Aaron Lindsay <aaron@os.amperecomputing.com> writes:

> On Feb 05 15:03, Alex Bennée wrote:
>> Aaron Lindsay <aaron@os.amperecomputing.com> writes:
>> > Assuming you're right that TCG is detecting "a io_readx/io_writex when
>> > ->can_do_io is not true", could we detect this case when it occurs and
>> > omit the instruction callbacks for the re-translation of the single
>> > instruction (allow the initial callback to stand instead of trying to
>> > turn back time, in a way, to prevent it)? Maybe there would have be some
>> > bookkeeping in the plugin infrastructure side rather than entirely
>> > omitting the callbacks when re-translating, in case that translation got
>> > re-used in a case which didn't hit the same behavior and shouldn't be
>> > skipped?
>> 
>> They are happening in two separate phases. The translation phase has no
>> idea what the runtime condition will be. Once we get to runtime it's too
>> late - and we trigger a new translation phase.
>
> I believe I understand why we can't catch the initial translation. To
> make sure I'm communicating well, my current understanding is that the
> timeline for this case goes something like:
>
> 1) translate large block of instructions, including ldr
> 2) attempt to execute ldr, calling instruction callback
> 3) notice that access is to IO, trigger re-translation of single
>    ldr instruction
> 4) execute block with single ldr instruction to completion, calling both
>    instruction and memory callbacks
>
> I was wondering if it would be possible to inform the re-translation in
> step 3 that it's for a re-translated IO access so that it could
> ultimately cause the second of the duplicate instruction callbacks to be
> omitted during execution in 4.

This is what I've done - re-executed blocks are compiled with CF_NOINSTR
which skips any instrumentation. If you could test the series I posted and
confirm the problem is solved that would be great:

  Subject: [PATCH  v2 00/21] plugins/next pre-PR (hwprofile, regression fixes, 
icount count fix)
  Date: Wed, 10 Feb 2021 22:10:32 +0000
  Message-Id: <20210210221053.18050-1-alex.bennee@linaro.org>

-- 
Alex Bennée