From owner-freebsd-hackers@FreeBSD.ORG  Sun Oct 12 00:41:11 2008
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 016CA106568A
	for <freebsd-hackers@freebsd.org>; Sun, 12 Oct 2008 00:41:11 +0000 (UTC)
	(envelope-from yuri@rawbw.com)
Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42])
	by mx1.freebsd.org (Postfix) with ESMTP id C7ED68FC0A
	for <freebsd-hackers@freebsd.org>; Sun, 12 Oct 2008 00:41:10 +0000 (UTC)
	(envelope-from yuri@rawbw.com)
Received: from eagle.syrec.org (c-67-188-126-36.hsd1.ca.comcast.net
	[67.188.126.36]) (authenticated bits=0)
	by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id m9C0goOo011165
	for <freebsd-hackers@freebsd.org>; Sat, 11 Oct 2008 17:42:50 -0700 (PDT)
Message-ID: <48F147A5.1040107@rawbw.com>
Date: Sat, 11 Oct 2008 17:41:09 -0700
From: Yuri <yuri@rawbw.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20081001)
MIME-Version: 1.0
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Is it possible to recover from SEGV?
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: yuri@rawbw.com
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Oct 2008 00:41:11 -0000

Let's say I have signal(3) handler set.
And I know exactly what instruction caused SEGV and why.

Is there a way to access from signal handler CPU registers as they
were before signal, modify some of them, clear the signal and
continue from the instruction that caused SEGV initially?

I see that if signal handler doesn't terminate the process signal is being
generated again and again. I understand it the way that the faulty
instruction is being rerun if signal handler didn't terminate the process.
rusage.ru_nsignals is also being incremented every time signal handler
is being called.

Yuri

PS: Of course I understand why SEGVs happen in general. I am trying to
understand if it's possible to use SEGV beyond the way it's commonly used.