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?