From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LmH2x-0006KD-Q8
	for qemu-devel@nongnu.org; Tue, 24 Mar 2009 20:32:43 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LmH2t-0006Jz-FT
	for qemu-devel@nongnu.org; Tue, 24 Mar 2009 20:32:43 -0400
Received: from [199.232.76.173] (port=59350 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LmH2t-0006Jw-Aa
	for qemu-devel@nongnu.org; Tue, 24 Mar 2009 20:32:39 -0400
Received: from mx20.gnu.org ([199.232.41.8]:5578)
	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 1LmH2s-00077G-R8
	for qemu-devel@nongnu.org; Tue, 24 Mar 2009 20:32:39 -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 1LmH2r-0005X8-Cr
	for qemu-devel@nongnu.org; Tue, 24 Mar 2009 20:32:37 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Kernel core dumps from qemu
Date: Wed, 25 Mar 2009 00:32:33 +0000
References: <20090324165401.GA2999@ldl.fc.hp.com> <49C921A6.3070202@redhat.com>
In-Reply-To: <49C921A6.3070202@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200903250032.34889.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
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: dave.anderson@redhat.com, Avi Kivity <avi@redhat.com>

> This looks useful.  I'd suggest a 'format' argument, so we can extend
> this later to dump in non-ELF formats (the Windows native memory dump
> format would be useful).

I'm not keen on having a plethora of different formats in qemu, especially if 
they are proprietary or poorly documented.  As long as it's done properly it 
should be straight forwarded to reconstruct everything else (vritual 
addresses, other formats) with offline debug tools.

What you actually want to do is use the the existing snapshot/savevm 
mechanism, and postprocess that into whatever format you want.

Paul