qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: gdb@gnu.org, QEMU Developers <qemu-devel@nongnu.org>,
	Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>,
	Luis Machado <luis.machado@linaro.org>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Subject: Best approach for supporting snapshots for QEMU's gdbstub?
Date: Fri, 14 May 2021 17:06:32 +0100	[thread overview]
Message-ID: <87y2chjmsf.fsf@linaro.org> (raw)

Hi,

I've been playing around with QEMU's reverse debugging support which
I have working with Pavel's latest patches for supporting virtio with
record/replay. Once you get the right command line it works well enough
although currently each step backwards requires replaying the entire
execution history until you get to the right point.

QEMU can quite easily snapshot the entire VM state so I was looking to
see what the best way to integrate this would be. As far as I can tell
there are two interfaces gdb supports: bookmarks and checkpoints.

As far as I can tell bookmarks where added as part of GDB's reverse
debugging support but attempting to use them from the gdbstub reports:

  (gdb) bookmark
  You can't do that when your target is `remote'

so I guess that would need an extension to the stub protocol to support?

The other option I found was checkpoints which seem to predate support
for reverse debugging. However:

  (gdb) checkpoint
  checkpoint: can't find fork function in inferior.

I couldn't tell what feature needs to be negotiated but I suspect it's
something like fork-events if the checkpoint mechanism is designed for
user space with a fork/freeze approach.

We could of course just add a custom monitor command like the
qemu.sstep= command which could be used manually. However that would be
a QEMU gdbstub specific approach.

The other thing would be to be more intelligent on QEMU's side and save
snapshots each time we hit an event, for example each time we hit a
given breakpoint. However I do worry that might lead to snapshots
growing quite quickly.

Any thoughts/suggestions?

-- 
Alex Bennée


             reply	other threads:[~2021-05-14 16:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 16:06 Alex Bennée [this message]
2021-05-15  6:12 ` Best approach for supporting snapshots for QEMU's gdbstub? Pavel Dovgalyuk
2021-05-17 16:49 ` Luis Machado
2021-05-17 17:27   ` Alex Bennée
2021-05-17 17:54     ` Luis Machado
2021-05-17 19:01     ` Peter Maydell
2021-05-18  5:26     ` Pavel Dovgalyuk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y2chjmsf.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=gdb@gnu.org \
    --cc=luis.machado@linaro.org \
    --cc=pavel.dovgalyuk@ispras.ru \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).