From owner-freebsd-hackers Wed Oct 21 07:27:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA24365 for freebsd-hackers-outgoing; Wed, 21 Oct 1998 07:27:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA24360 for ; Wed, 21 Oct 1998 07:27:16 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id HAA02579; Wed, 21 Oct 1998 07:27:38 -0700 (PDT) Message-Id: <199810211427.HAA02579@implode.root.com> To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: Handling page faults in user space ? In-reply-to: Your message of "Wed, 21 Oct 1998 08:44:43 BST." <199810210744.IAA09732@labinfo.iet.unipi.it> From: David Greenman Reply-To: dg@root.com Date: Wed, 21 Oct 1998 07:27:38 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >causes first a fault and then the faulting instruction is restarted and >produces the right output. What is missing is how to know, in the >signal handler, the fault virtual address and maybe IP associated to >the faulting instruction. > >Ideas anyone ? Yes, that is supported. The fault VA is passed back via the sigcontext struct, sc_err. A pointer to the sigcontext is passed into the signal handler as the third arg. See the sigaction(2) man page. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message