From owner-freebsd-current Thu Sep 30 13:21:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id EA332152E3 for ; Thu, 30 Sep 1999 13:21:46 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11WmjO-0007tu-00; Thu, 30 Sep 1999 20:23:10 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id WAA08954; Thu, 30 Sep 1999 22:21:37 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <37F3C651.EC9305B7@scc.nl> Date: Thu, 30 Sep 1999 22:21:37 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: John Polstra , current@FreeBSD.ORG Subject: Re: Now that sigcontext is gone ... References: <199909301942.NAA29570@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > I'm trying to digest the recent signal changes and get a handle on > > what I need to do to make Modula-3 work. There is code in the runtime > > currently which catches SIGBUS and uses the sigcontext's "sc_err" > > member to find out the faulting address. That should be replaced > > by the siginfo_t's "si_addr" member. But as far as I can tell from > > grepping the kernel sources, that functionality isn't implemented. > > > > Is that right? Any ideas regarding a work-around? > > I'm also very interested in this, so if you could post this information > publically, it would be greatly appreciated.... That's right, it's not implemented yet. The work-around is to use ucontext. uc_mcontext contains the trapframe which has tf_err (uc.uc_mcontext.mc_tf.tf_err). I haven't paid any attention to implement any of the fields in siginfo_t because that may only have complicated matters. It may be required to do some non-trivial rewriting to get all the information at the right place. Since real-time signals are also in the pipeline and also may have specific needs, both "problems" can best be considered at the same time (IMO). -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message