From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:46057)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1RG9PR-0006T1-LO
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 09:08:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1RG9PI-0005DX-Ba
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 09:08:45 -0400
Received: from verein.lst.de ([213.95.11.211]:54656 helo=newverein.lst.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1RG9PI-0005DO-4R
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 09:08:36 -0400
Date: Tue, 18 Oct 2011 15:08:30 +0200
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20111018130830.GA27797@lst.de>
References: <4E9D3804.5040000@cn.fujitsu.com> <4E9D3847.8040202@siemens.com>
	<4E9D3965.4090003@cn.fujitsu.com> <4E9D394E.6050907@siemens.com>
	<20111018083416.GL8872@amd.home.annexia.org>
	<4E9D3A80.10402@siemens.com> <4E9D3B29.5060207@siemens.com>
	<4E9D57C6.8040809@redhat.com> <20111018104257.GA24311@lst.de>
	<4E9D756B.7060509@siemens.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E9D756B.7060509@siemens.com>
Subject: Re: [Qemu-devel] [Question] dump memory when host pci device
	is	used by guest
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, "Richard W.M. Jones" <rjones@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>, Christoph Hellwig <hch@lst.de>, qemu-devel <qemu-devel@nongnu.org>

On Tue, Oct 18, 2011 at 02:47:39PM +0200, Jan Kiszka wrote:
> >> Crash can also do live system analysis. :)
> > 
> > crash in fact is gdb - with a lot of additional commands.
> 
> Is there a trick to make it work against a gdbserver?

No idea.  I just noticed that crash was built around a gdb source
tree and additional files when I had to hack it for a new kernel
version a while ago.

The optimum would be if all the crash changes were merged back
into upstream gdb, but I'm not sure the gdb community would like
to see all that very linux kernel specific code (especially given that it's
very version dependent)