From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LmPPZ-0001um-Qf for qemu-devel@nongnu.org; Wed, 25 Mar 2009 05:28:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LmPPU-0001sl-5U for qemu-devel@nongnu.org; Wed, 25 Mar 2009 05:28:37 -0400 Received: from [199.232.76.173] (port=57673 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LmPPT-0001si-Vv for qemu-devel@nongnu.org; Wed, 25 Mar 2009 05:28:32 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43557) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LmPPT-0003dh-GK for qemu-devel@nongnu.org; Wed, 25 Mar 2009 05:28:31 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2P9SUMH006041 for ; Wed, 25 Mar 2009 05:28:30 -0400 Message-ID: <49C9F93C.7090803@redhat.com> Date: Wed, 25 Mar 2009 11:28:28 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Kernel core dumps from qemu References: <20090324165401.GA2999@ldl.fc.hp.com> <49C921A6.3070202@redhat.com> <200903250032.34889.paul@codesourcery.com> In-Reply-To: <200903250032.34889.paul@codesourcery.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: dave.anderson@redhat.com Paul Brook wrote: >> 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. > Well, the physical elf format together with postprocessing tools to convert to virtual elf or Windows dumps seem like a good solution. > What you actually want to do is use the the existing snapshot/savevm > mechanism, and postprocess that into whatever format you want. > savevm falls into the poorly documented category, I'm afraid. But it does have the advantage of carrying device state, not just cpu and memory state, which might be useful in extreme situations. -- error compiling committee.c: too many arguments to function