Re: [RFC PATCH v3 11/11] tests: add plugin asserting correctness of discon event's to_pc

[Pierrick Bouvier]

On 12/6/24 00:42, Julian Ganz wrote:
> Hi Pierrick,
>
> December 5, 2024 at 11:28 PM, "Pierrick Bouvier" wrote:
> > On 12/5/24 13:22, Julian Ganz wrote:
> > >   December 5, 2024 at 6:30 PM, "Pierrick Bouvier" wrote:
> > > > We can store the next_expected pc for each instruction (from 
> > > > current_instruction + insn_length), and we should be able to compare that with 
> > > > the expected from_pc.
> > > >   This is mostly what contrib/plugins/cflow.c does.
> > > >
> > > >   With that, we can test from_pc.
> > >   I'm not confident that this will work reliably for branch, jump and
> > >   other "interesting" instructions. But I can have a closer look at the
> > >   cflow plugin and try to figure out how that plugin handles those cases.
> > It won't work for latest instructions in a tb (because we don't know what will 
> > be the next one), but should be good for all the others cases.
>
> IIUC qemu will schedule interrupts "opportunistically" between tb
> executions. If that's the case we'll observe interrupts exclusively
> after the last instruction in a tb. That strikes me as a serious
> limitation.

To reuse fancy vocabulary, maybe we should have a distinction between 
inferable interruptions (interrupt instruction) and uninferable 
interrupts, triggered by an external event.

In the latter, it *might* be acceptable to not provide a from_pc (let's 
say a value 0), because there is no useful information in itself, except 
creating random edges in the control flow graph, which we don't want to do.

What do you think of it?

> Regards,
> Julian Ganz