On Tue, 13 Oct 2026 at 14:01, Marc-André Lureau
<[email protected]> wrote:
>
> Hi
>
> On Tue, Oct 13, 2026 at 12:51 PM Alex Bennée <[email protected]> wrote:
> >
> > Marc-André Lureau <[email protected]> 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.
thanks
-- PMM
