From owner-freebsd-current Fri Oct 4 6:53: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1890037B401 for ; Fri, 4 Oct 2002 06:53:04 -0700 (PDT) Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 889B443E42 for ; Fri, 4 Oct 2002 06:53:03 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id g94Dr1Ct012411; Fri, 4 Oct 2002 09:53:02 -0400 (EDT) Date: Fri, 4 Oct 2002 09:53:01 -0400 (EDT) From: Daniel Eischen To: Bruce Evans Cc: current@FreeBSD.ORG, "Andrey A. Chernov" Subject: Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6)) In-Reply-To: <20021004192346.M7132-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 4 Oct 2002, Bruce Evans wrote: > On Thu, 3 Oct 2002, Daniel Eischen wrote: > > > Can you try the patch at: > > > > http://people.freebsd.org/~deischen/sys.diffs > > > > I haven't had a chance to compile or test it, but it should > > be easy enough to fix if it doesn't (compile). > > It seems a bit fragile. As I understand it, it loads a clean FP state > if the state in the ucontext is too messed up to use, and changes > some magic numbers to be more magic so that it is easier to detect > messed up states. But loading a clean FP state is the wrong thing to > do if it wasn't clean to begin with. I would have thought the current > hack of saving it in the pcb would work better. Maybe combining these > hacks would work better (load from the pcb, but only if there is no > alternative, and don't load blindly if !PCB_NPXINITDONE). I'll try this. > > I'm still not exactly sure why this causes problems for the > > modula 3 run-time. I think Bruce may be right in that the > > modula 3 libraries/run-time need to be rebuilt with the > > larger ucontext. > > I have no idea about the details. Rebuilding old binaries to fix > binary compatibility problems is not a solution. I don't think the modula 3 run-time library is written in C/C++, so any change in the size of a ucontext may require a source code change for any modula 3 structures that correspond to/contain it. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message