* Peter Maydell ([email protected]) wrote: > 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.
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 |_______/
