QEMU's handling of the program counter is special in so far as the
translator avoids setting it whenever possible. As the PC is available
at translation time lets avoid confusion by just filtering the program
counter from the list of available registers.

Update the documentation with some notes about the register access and
calling out the behaviour of the PC.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2208
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/devel/tcg-plugins.rst | 15 +++++++++++++++
 plugins/api.c              |  5 +++++
 2 files changed, 20 insertions(+)

diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst
index 9cc09d8c3da..656df012e77 100644
--- a/docs/devel/tcg-plugins.rst
+++ b/docs/devel/tcg-plugins.rst
@@ -151,6 +151,21 @@ Unsuccessful operations (i.e. faults) will not be visible to memory
 instrumentation although the execution side effects can be observed
 (e.g. entering a exception handler).
 
+Register Values
++++++++++++++++
+
+Callbacks registered with the ``QEMU_PLUGIN_CB_R_REGS`` flags can read
+the current register values of the system. The plugin need to request
+the list of available registers after a vcpu has initialised by
+calling ``qemu_plugin_get_registers`` and using the supplied handle to
+query the values when executing the callback.
+
+.. Note:: the program counter (PC) is not available through this
+          interface but can be queried at translation time by using
+          the ``qemu_plugin_insn_vaddr`` and
+          ``qemu_plugin_insn_haddr`` on the instruction handle.
+
+
 System Idle and Resume States
 +++++++++++++++++++++++++++++
 
diff --git a/plugins/api.c b/plugins/api.c
index 8fa5a600ac3..fc3477acf2d 100644
--- a/plugins/api.c
+++ b/plugins/api.c
@@ -448,6 +448,11 @@ static GArray *create_register_handles(GArray *gdbstub_regs)
             continue;
         }
 
+        /* skip the program counter */
+        if (g_ascii_strncasecmp(grd->name, "pc", 2) == 0) {
+            continue;
+        }
+
         /* Create a record for the plugin */
         desc.handle = GINT_TO_POINTER(grd->gdb_reg);
         desc.name = g_intern_string(grd->name);
-- 
2.39.2

On 3/5/24 07:12, Alex Bennée wrote:
> +        /* skip the program counter */
> +        if (g_ascii_strncasecmp(grd->name, "pc", 2) == 0) {
> +            continue;
> +        }

The pc is not always named pc.

For s390x it is "pswa"; for x86_64 it is "rip".

For i386, "eip" is a component of the composite virtual address (pc = eip + cs_base) and 
cannot be queried in the same way.


r~

On Tue, 5 Mar 2024 at 17:13, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> QEMU's handling of the program counter is special in so far as the
> translator avoids setting it whenever possible. As the PC is available
> at translation time lets avoid confusion by just filtering the program
> counter from the list of available registers.
>
> Update the documentation with some notes about the register access and
> calling out the behaviour of the PC.
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2208
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  docs/devel/tcg-plugins.rst | 15 +++++++++++++++
>  plugins/api.c              |  5 +++++
>  2 files changed, 20 insertions(+)
>
> diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst
> index 9cc09d8c3da..656df012e77 100644
> --- a/docs/devel/tcg-plugins.rst
> +++ b/docs/devel/tcg-plugins.rst
> @@ -151,6 +151,21 @@ Unsuccessful operations (i.e. faults) will not be visible to memory
>  instrumentation although the execution side effects can be observed
>  (e.g. entering a exception handler).
>
> +Register Values
> ++++++++++++++++
> +
> +Callbacks registered with the ``QEMU_PLUGIN_CB_R_REGS`` flags can read
> +the current register values of the system. The plugin need to request
> +the list of available registers after a vcpu has initialised by
> +calling ``qemu_plugin_get_registers`` and using the supplied handle to
> +query the values when executing the callback.
> +
> +.. Note:: the program counter (PC) is not available through this
> +          interface but can be queried at translation time by using
> +          the ``qemu_plugin_insn_vaddr`` and
> +          ``qemu_plugin_insn_haddr`` on the instruction handle.
> +
> +
>  System Idle and Resume States
>  +++++++++++++++++++++++++++++
>
> diff --git a/plugins/api.c b/plugins/api.c
> index 8fa5a600ac3..fc3477acf2d 100644
> --- a/plugins/api.c
> +++ b/plugins/api.c
> @@ -448,6 +448,11 @@ static GArray *create_register_handles(GArray *gdbstub_regs)
>              continue;
>          }
>
> +        /* skip the program counter */
> +        if (g_ascii_strncasecmp(grd->name, "pc", 2) == 0) {
> +            continue;
> +        }

Is the program counter always named "pc"? For instance
gdb-xml/microblaze-core.xml suggests it's named "rpc" there.
And on x86-64 I think from the gdb protocol point of view it
is named "rip" and the gdb "$pc" alias is handled on the gdb
side, but maybe I'm wrong.

Does the same problem apply to other registers whose value
we fix up after-the-fact via the restore_state_to_opc hook,
like the SPARC npc register, or the 32-bit Arm Thumb
IT bits in the CPSR?

thanks
-- PMM