Re: Detecting Faulting Instructions From Plugins

["Alex Bennée" <alex.bennee@linaro.org>]

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.

Currently we invalidate the previous TB and save the new TB in the
translation cache before restarting the execution loop so the new TB
gets picked up. However we could certainly have a different mechanism
which ensures the next block is not cached. I think if we extend CFLAGS
down to gen_intermediate_code and translator_loop we could ask it not to
instrument that block. It wouldn't be the most efficient solution but
then again this is icount so...

Richard,

What do you think?


>
> -Aaron


-- 
Alex Bennée