From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM9He-0003em-TA for qemu-devel@nongnu.org; Wed, 01 Jul 2009 19:32:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM9Ha-0003Vy-53 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 19:32:10 -0400 Received: from [199.232.76.173] (port=37631 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM9HZ-0003VY-Tx for qemu-devel@nongnu.org; Wed, 01 Jul 2009 19:32:05 -0400 Received: from mx20.gnu.org ([199.232.41.8]:30341) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MM9HZ-0005N7-MR for qemu-devel@nongnu.org; Wed, 01 Jul 2009 19:32:05 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM9HY-0001ba-2J for qemu-devel@nongnu.org; Wed, 01 Jul 2009 19:32:04 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 3/5] linux-user: do not avoid dumping of qemu itself Date: Thu, 2 Jul 2009 00:31:59 +0100 References: <20090630170145.GA7830@kos.to> <87r5x03zx2.fsf@lechat.rtp-net.org> In-Reply-To: <87r5x03zx2.fsf@lechat.rtp-net.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907020032.00212.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Arnaud Patard (Rtp)" Cc: Riku Voipio , qemu-devel@nongnu.org > >> It sounds like WCOREDUMP is one of those things that just isn't going to > >> work. i.e. we have to just accept the limitation and xfail the test. > > > > If this how people feel, I'll be glad to drop this patch. > > well, as I said either we fix it or we accept that the emulation is not > perfect and judge that this feature is worth it. It's not quite that simple. I think this is a case of someone blindly "fixing" a testsuite without any consideration of what is actually being implemented. IMO a host core dump is for most purposes useless[1], and dumping guest state to a different location is a bug. Given the choice between dumping guest core in the "normal" location and setting the WCOREDUMP flag, the former seems much more useful. Paul [1] A host core dump may be useful for debugging qemu itself, but that's a fairly specialized corner case, and not necessarily something we want to be exposing to users.