On 4/16/24 19:40, Richard Henderson wrote:
On 4/16/24 17:35, Pierrick Bouvier wrote:
On 4/15/24 21:06, Richard Henderson wrote:
Based-on: 20240404230611.21231-1-richard.hender...@linaro.org
("[PATCH v2 00/21] Rewrite plugin code generation")

This is an attempt to fix
https://gitlab.com/qemu-project/qemu/-/issues/2208
("PC is not updated for each instruction in TCG plugins")

I have only updated target/i386 so far, but basically all targets
need updating for the new callbacks.  Extra points to anyone who
sees how to avoid the extra code duplication.  :-)


Thanks for the series Richard. It looks good to me.

Besides reviewing individual commits, I have a more general question.
  From some discussions we had, it seems like that previously gdb stub was 
correctly
updating all register values, and that it has been dropped at some point.

Normally gdbstub does not run in the middle of a TB -- we end normally 
(single-step,
breakpoint) or raise an exception (watchpoint).  Only then, after TCG state has 
been made
consistent, does gdbstub have access to the CPUState.


That makes sense.
 >
Was it for performance reasons, or an architectural change in QEMU?
Is gdb stub the right way to poke register values for plugins?

I don't know exactly why some registers are not updated correctly in this 
context, but it
seems like we are trying to fix this afterward, instead of identifying root 
cause.

The one or two registers are not updated continuously for performance reasons.  
And
because they are not updated during initial code generation, it's not easy to 
do so later
with plugin injection.  But recovering that data is what the unwind info is for 
-- a bit
expensive to access that way, but overall less, with the expectation that it is 
rare.


Thanks for the description, I understand better the approach you picked for that issue.


r~

Reply via email to