From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MR1VY-00043Z-Lv
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 06:14:40 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MR1VT-00041e-Uz
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 06:14:40 -0400
Received: from [199.232.76.173] (port=35010 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MR1VT-00041U-6X
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 06:14:35 -0400
Received: from mx20.gnu.org ([199.232.41.8]:17300)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1MR1VS-0002Kg-W1
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 06:14:35 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1MR1VM-0006DF-DW
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 06:14:28 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] monitor: Add port write command
Date: Wed, 15 Jul 2009 11:14:20 +0100
References: <4A5C3FBB.10306@siemens.com>
	<200907142030.27019.paul@codesourcery.com>
	<20090715073451.GF28046@redhat.com>
In-Reply-To: <20090715073451.GF28046@redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200907151114.21482.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>, Gleb Natapov <gleb@redhat.com>

> > I'd be reluctant to expose the savevm state to the user.
> >
> > For debugging qemu I don't see it providing any real benefit over firing
> > up GDB and poking directly at the device directly.
>
> Not all environments where you need to debug things have gdb, qemu
> sources or even non striped qemu binary.

If you don't have qemu sources than I really don't care. By definition you're 
not going to be able to do anything useful even if you do figure out what the 
problem is.  Note that there's no requirement that you run gdb on the target 
itself. Remote debug (e.g. via gdbserver on linux) is a well established 
technique.

Likewise for debugging stripped production binaries, my answer is "don't do 
that". There are very rare cases where a bug goes away on a debug build, but 
in those cases any instrumentation you add is also liable to make the bug go 
away.

Paul