From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NrpGc-00052w-Rt
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 05:10:18 -0400
Received: from [199.232.76.173] (port=55395 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NrpGb-00052h-UE
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 05:10:18 -0400
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <pbonzini@redhat.com>) id 1NrpGa-0003Xe-RX
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 05:10:17 -0400
Received: from mx1.redhat.com ([209.132.183.28]:37714)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <pbonzini@redhat.com>) id 1NrpGa-0003XK-D2
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 05:10:16 -0400
Message-ID: <4BA09C72.9060201@redhat.com>
Date: Wed, 17 Mar 2010 10:10:10 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort()
	or  cpu_abort()
References: <f43fc5581003130656j408f64bfp7fe4bf486c625624@mail.gmail.com>
	<m3sk82nj16.fsf@blackfin.pond.sub.org>
	<f43fc5581003151023g354dc74cr989f3373f5f1de9a@mail.gmail.com>
	<m3vdcx8ma9.fsf@blackfin.pond.sub.org>
	<hnnf7e$8f9$1@dough.gmane.org>
	<m3ljds3auv.fsf@blackfin.pond.sub.org>
	<20100316175523.GD19160@shareable.org>
In-Reply-To: <20100316175523.GD19160@shareable.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Jamie Lokier <jamie@shareable.org>
Cc: Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org

On 03/16/2010 06:55 PM, Jamie Lokier wrote:
> A guest program is also allowed to trap SIGABRT with a signal handler,
> and that does have some uses.  E.g. cleaning up temporary files and
> shmem segments following a crash when calling 3rd party code.
>
> Whatever the guest does with SIGABRT, it should not result in_QEMU_
> crashing - whether due to abort() returning, or QEMU's control flow
> jumping to the guest's signal handler from an unexpected location.

That's very hard to ensure however if QEMU was already in unstable 
state, as witnessed by its call to abort().  Things can only go downhill.

Maybe there should be a qemu_abort wrapper (and a QEMU_ASSERT companion) 
that does simply abort/assert under system emulation, but under 
user-mode emulation does

   signal (SIGABRT, SIG_DFL);
   abort ();

Paolo