Re: Detecting Faulting Instructions From Plugins

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

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

> On Jan 29 22:23, Aaron Lindsay wrote:
>> 1. Is this considered a bug or a "feature"?
>> 2.a. If a bug, is there a good way to detect this from inside the
>> 	 tcg/plugin infrastructure and avoid calling the callback for the
>> 	 faulting execution of the instruction?
>> 2.b. If a "feature", is there a good way to detect this from my plugin?
>
> I think I've convinced myself the current behavior *is* a "feature", and
> working as intended since the instruction can be considered
> architecturally committed, even if it faults (ARM statement).

Yes I think that's correct. I assume in between the page-fault handler
has run and ensured the page is properly mapped and then returned to
*re*-execute the instruction.

> But I am
> still unsure of the best way to detect whether a load/store instruction
> has faulted from within the plugin interface, so I welcome thoughts
> there.

A hacky method would be to:

  a) track last executed PC on a per-vCPU basis in the callbacks for
  load/store
  b) have a specific callback handler for the head of the vector table
  for synchronous exceptions.

It wouldn't be ideal because you need some knowledge of where the table
is and depending on the architecture the entry may be shared between
synchronous (i.e. the last instruction that attempted to execute) and
asynchronous ones (e.g. a timer just happened to fire).

If we get to the point we can expose the register values to the plugin
then it becomes a much simpler operation because there will be state
information exposed somewhere in the register state.

>
> -Aaron


-- 
Alex Bennée