From owner-freebsd-current Thu Sep 30 16:19:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A395514A0D for ; Thu, 30 Sep 1999 16:19:06 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from d219.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id JAA03098; Fri, 1 Oct 1999 09:19:43 +1000 Date: Fri, 1 Oct 1999 09:18:35 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: John Polstra Cc: marcel@scc.nl, current@FreeBSD.ORG Subject: Re: Now that sigcontext is gone ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 Sigcontext will have to come back, since it is a standard BSD interface. Recent signal changes break even its source-level compatibility. Previous signal changes managed to preserve even its binary compatibility by keeping things the same for the !SA_SIGINFO case, but the next round of those changes might have broken binary compatibility by adding floating point context. BTW, struct sigcontext seems to be documented only in sigreturn.2, and that documentation is more than 3 stages behind reality. sigreturn() now uses ucontext_t, and the documented struct sigcontext is only for an old i386 version (Lite2 documents a "machine-independent" but inadequate version). It is missing sc_gs, sc_fs, sc_trapno and sc_err at the end. Adding these fields broke binary compatibility. > 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? The functionality of sc_trapno also seems to be unimplemented. These fields are not documented, so you shouldn't be using them :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message