From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMBtd-0005Oz-0u for qemu-devel@nongnu.org; Wed, 01 Jul 2009 22:19:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMBtX-0005OT-Ed for qemu-devel@nongnu.org; Wed, 01 Jul 2009 22:19:32 -0400 Received: from [199.232.76.173] (port=52550 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMBtX-0005OQ-97 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 22:19:27 -0400 Received: from mail2.shareable.org ([80.68.89.115]:35879) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MMBtX-0003yR-0A for qemu-devel@nongnu.org; Wed, 01 Jul 2009 22:19:27 -0400 Date: Thu, 2 Jul 2009 03:19:21 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 3/5] linux-user: do not avoid dumping of qemu itself Message-ID: <20090702021921.GB18372@shareable.org> References: <20090630170145.GA7830@kos.to> <87r5x03zx2.fsf@lechat.rtp-net.org> <200907020032.00212.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907020032.00212.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Riku Voipio , qemu-devel@nongnu.org, Arnaud Patard Paul Brook wrote: > > >> 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. It's a really minor corner case, but I wonder if it's worth adding a prctl() option or some bit in the info passed to sigqueue(), to the Linux kernel to set the WCOREDUMP flag on exit. Meaning "app has coredumped itself". > [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. It would make sense to set RLIMIT_CORE to zero very early in qemu-user, and then someone debugging qemu-user can easily change RLIMIT_CORE from gdb while it is running. -- Jamie