[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH 1/2] monitor: Add dump-stack command

From: Dr. David Alan Gilbert
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 1/2] monitor: Add dump-stack command
Date: Wed, 8 May 2019 14:15:05 +0100
User-agent: Mutt/1.11.4 (2019-03-13)

* Markus Armbruster (address@hidden) wrote:
> "Dr. David Alan Gilbert" <address@hidden> writes:
> > * Markus Armbruster (address@hidden) wrote:
> >> Suraj Jitindar Singh <address@hidden> writes:
> >> 
> >> > Add a monitor command "dump-stack" to be used to dump the stack for the
> >> > current cpu.
> >> 
> >> I guess this is just for debugging.  Correct?
> >> 
> >> Shouldn't this be "info stack", to match "info registers" and "info
> >> cpustats"?
> >
> > Since this is primarily about walking the guests stack frames and not
> > walking qemu internal data structures, I think it's probably OK to be
> > a dump-stack rather than an info subcommand.
> Well, "info registers" is also about the guest's state and not QEMU
> internal state.  Arguably, so are "info pic", "info tlb", ...

When doing an 'info registers' you don't have to interpret or parse 
much guest state, you just print it, and it's guest state that's
held separately (similarly a separate piece of state for info pic, info
tlb etc).  You might check the register state a little when you
decide which bits to print or how to format them, but that's about as
far as it goes.  So each of the 'info's (or query for qmp) correspond
to one logical chunk of qemu and/or guest state.

Printing a stack is a much hairier thing, with knowledge of guest
stack layout and potentially some heuristics.

> We have a long-standing tradition of using "info" for "pure"
> information-retrieving commands.  I rather like that pattern.
> Ultimately your choice as the HMP maintainer, of course.


Dr. David Alan Gilbert / address@hidden / Manchester, UK

reply via email to

[Prev in Thread] Current Thread [Next in Thread]