Re: Detecting Faulting Instructions From Plugins

[Aaron Lindsay]

On Feb 11 17:27, Alex Bennée wrote:
> 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>

Yes, I absolutely will. I worked on getting some local changes rebased
on top of these already this morning and am hoping to finish that up
today and to be able to report back by tomorrow.

Thanks for the quick turnaround on a fix!

-Aaron