Date: Fri, 4 Oct 2002 09:53:01 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.ORG, "Andrey A. Chernov" <ache@nagual.pp.ru> Subject: Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6)) Message-ID: <Pine.GSO.4.10.10210040934300.10118-100000@pcnet1.pcnet.com> In-Reply-To: <20021004192346.M7132-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10210040934300.10118-100000>