From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHNOT-0001Xl-MJ for qemu-devel@nongnu.org; Thu, 18 Jun 2009 15:35:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHNOT-0001XZ-5l for qemu-devel@nongnu.org; Thu, 18 Jun 2009 15:35:29 -0400 Received: from [199.232.76.173] (port=33552 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHNOS-0001XW-Vs for qemu-devel@nongnu.org; Thu, 18 Jun 2009 15:35:29 -0400 Received: from lechat.rtp-net.org ([88.191.19.38]:60718) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MHNOS-0000bW-Eo for qemu-devel@nongnu.org; Thu, 18 Jun 2009 15:35:28 -0400 From: Arnaud Patard (Rtp) Subject: Re: [Qemu-devel] linux-user and signal handling References: <87fxdxsqks.fsf@lechat.rtp-net.org> <87bpolsh9o.fsf@lechat.rtp-net.org> <200906181735.09280.uli@suse.de> <200906181808.15408.uli@suse.de> <877hz9se21.fsf@lechat.rtp-net.org> <20090618171439.GA32373@caradoc.them.org> <20090618184519.GA24046@kos.to> Date: Thu, 18 Jun 2009 21:40:24 +0200 In-Reply-To: <20090618184519.GA24046@kos.to> (Riku Voipio's message of "Thu\, 18 Jun 2009 21\:45\:20 +0300") Message-ID: <873a9xs53r.fsf@lechat.rtp-net.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Riku Voipio Cc: qemu-devel@nongnu.org Riku Voipio writes: > On Thu, Jun 18, 2009 at 01:14:39PM -0400, Daniel Jacobowitz wrote: >> On Thu, Jun 18, 2009 at 06:27:02PM +0200, Arnaud Patard wrote: >> > Ulrich Hecht writes: >> > >> > > On Thursday 18 June 2009, Ulrich Hecht wrote: >> > >> And the culprit indeed >> > >> seems to be edf8e2af1453ce56c72b2f25a745e3734177a05d >> > > >> > > Specifically, it's the part in force_sig() that sets the core limit to 0 >> > > to prevent a core dump of qemu itself that causes the wrong core bit. >> > > Remove it, and the test passes. No idea how to fix that properly, >> > > though. >> > >> > ok. That's interesting... Will look at that. Thanks a lot ! >> >> Sounds to me like what's happening is a feature... trading off a >> host core dump for a target core dump. > > Or to be more specific, trading off a unneeded core dump of a qemu process > (since we got a core dump of the target process) to not having core bit set > in exit status. > > If people depend on WCOREDUMP(), we can remove that bit of eliminating > the host process coredump. I understand the idea is to get coredump for the target and not of the host. What's worrying me is that it should be transparent to the target and it's not the case. It would be nice if this can be fixed. If this can't be done, maybe this can be clearly documented that the core bit is corrupted by qemu and stop worrying about that. Getting a bug-free emulation is very hard after all :) Arnaud