qemu-devel
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/2] monitor: Add dump-stack command
Date: Tue, 07 May 2019 13:21:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Alexey Kardashevskiy <address@hidden> writes:

> On 02/05/2019 10:44, David Gibson wrote:
>> On Wed, May 01, 2019 at 03:35:21PM +1000, Suraj Jitindar Singh wrote:
>>> Add a monitor command "dump-stack" to be used to dump the stack for the
>>> current cpu.
>> 
>> So, you can already get guest backtraces by using the gdbstub
>
> Not in the field - this requires QEMU to run with -s which is not
> usually the case.

If I understand help correctly, you can hot-add a gdbserver with HMP
command gdbserver.  Makes me think ...

> But since we almost always deal with QEMUs run by libvirt and HMP/QMP is
> always available, one could write a script doing QMP's
> "human-monitor-command x/16g" or "virsh qemu-monitor-command --hmp
> x/16g" to read the guest memory and MSR:LE and dump the stack with the
> exception frame.
>
>
>> functionality.  I can see some benefit in allowing this more easily
>> through hmp, but whether it's worth the code size, I'm less certain.

... David's "why not use gdb" should be considered once more.

> It still seems easier than running an external script talking to HMP/QMP
> as you would not want to write such script in bash but rather in a
> better language which might not be installed on the client machine (like
> missing python3 on many RHEL :) ). Thanks,

Your point "while it's possible to trace the stack with nothing but
x/16g and a general purpose programming language, we shouldn't make our
users jump through this hoop" is valid.

However, the new command is actually competing with gdb.  How much of
gdb do we want to build into QEMU to avoid the inconvenience of having
to install gdb and hot-add a gdb server?



reply via email to

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