On 10/21/24 11:47, Alex Bennée wrote:
Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:
Hi Julian,
On 10/19/24 09:39, Julian Ganz wrote:
Some analysis greatly benefits, or depends on, information about
interrupts. For example, we may need to handle the execution of a new
translation block differently if it is not the result of normal program
flow but of an interrupt.
Even with the existing interfaces, it is more or less possible to
discern these situations, e.g. as done by the cflow plugin. However,
this process poses a considerable overhead to the core analysis one may
intend to perform.
I agree it would be useful. Beyond the scope of this series, it would
be nice if we could add a control flow related API instead of asking
to plugins to do it themselves.
I think there is a balance to be had here. We don't want to
inadvertently expose QEMU internals to the plugin API. With this series
at least we rely on stuff the front-end knows which can at least be
tweaked relatively easily.
You're right. Maybe a good way to find the balance is to identify the
real use cases behind this need.
If we would provide something like this, is there still a value to add
an API to detect interrupt/exceptions/traps events?
Note: It's not a critic against what you sent, just an open question
on *why* it's useful to access this QEMU implementation related
information vs something more generic.
<snip>
It would be good to have the opinion of the front-end maintainers if
this is too burdensome or easy enough to manage.
