Re: [PATCH v2 04/10] gdbstub: add gdb_register_internal_coprocessor()

["Dr. David Alan Gilbert" <dave@treblig.org>]

* Peter Maydell (peter.maydell@linaro.org) wrote:
> On Tue, 13 Oct 2026 at 14:01, Marc-André Lureau
> <marcandre.lureau@redhat.com> wrote:
> >
> > Hi
> >
> > On Tue, Oct 13, 2026 at 12:51 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> > >
> > > Marc-André Lureau <marcandre.lureau@redhat.com> writes:
> > >
> > > > Add support for registering coprocessor features that are only visible
> > > > to QEMU's internal APIs (HMP monitor $register expressions, plugins) but
> > > > hidden from GDB's target description XML.
> > > >
> > > > When a feature is registered as internal:
> > > > - It is excluded from the target.xml sent to GDB
> > > > - Its XML is not served via qXfer:features:read
> > > > - 'p'/'P' packets for internal register numbers return E14
> > > >
> > > > This is useful for exposing system registers to the HMP monitor without
> > > > affecting GDB's register namespace. Exposing aliases or synthetic
> > > > registers through GDB's target description can cause problems: name
> > > > collisions with GDB's pseudo-registers, independent register caching,
> > > > and missing DWARF unwind rules.
> > >
> > > Hmm are they *that* useful for HMP then?
> > >
> > > The front-ends do limit what they export to gdb (see for example
> > > ARM_CP_NO_GDB) generally because reading them causes side-effects. Those
> > > restrictions are also a reason to limit them from the HMP interface.
> >
> > I am not a user, but I can imagine they are useful for developers.
> >
> > I would like to be able to implement "info registers" purely based on
> > QMP for ex.
> 
> Yes, getting rid of the current hacks that "info registers" does will
> be a very nice cleanup.
> 
> I think that the reason we get this internal-only interface is
> that gdb itself sets up pseudo-registers for various things that
> are nice for a human to have but are not directly exposed that
> way in the XML. So for HMP we can either:
>  (a) not expose that human-facing convenience at all
>  (b) reimplement the equivalent of the pseudo-registers and
>      aliases, to the extent that we care to do so, in a way
>      that they don't appear in the XML we expose to gdb
> 
> Personally I'm sceptical of the utility of the "info registers"
> interface -- if you want to see what the guest CPU is doing then
> you're going to have a much better time connecting gdb to the debug
> stub rather than using the extremely rudimentary monitor commands --
> but "preserve the existing functionality" is a much easier path
> towards getting this cleaned up than trying to get agreement that
> we can drop some aspects of it, so I support doing that.

It's useful for getting hints on hung VMs;  getting a gdb into a container
on some cluster of hosts and someone letting you poke with it is
often pretty hard.
Getting an admin to run one command when they find a hung VM is more doable.
(Similarly in cases where they wont send you a full vm dump)

Dave

> thanks
> -- PMM
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/