Date: Fri, 16 Oct 1998 19:56:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter@netplex.com.au (Peter Wemm) Cc: mike@smith.net.au, dg@root.com, freebsd-alpha@FreeBSD.ORG Subject: Re: kernel traps on boot.. Message-ID: <199810161956.MAA24313@usr04.primenet.com> In-Reply-To: <199810160644.OAA16113@spinner.netplex.com.au> from "Peter Wemm" at Oct 16, 98 02:44:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> NULL dereferencing is not the same as an unaligned access. There is no > clear recovery process for NULL dereferences, the only sensible thing to > do is to panic before things get too bad. The system is well and truely > off the rails by now. Actually, SVR4 will, by default, trap a pointer dereference of page zero, and map a read-only zero page in its place. Writes to the page are ignored. This is the default behaviour, although there is a kernel tunable to allow you to turn the behaviour off, many programs that shipped on the system assumed "strcpy(x, NULL)" worked. > However, with a kernel that was written in a 32 bit environment is is > evolving to 64 bit, it's only natural that some code will run afoul of new > restrictions. If the only thing that is wrong is the alignment and > recovery is possible (although inconvenient), then there's no *benefit* in > panicing with dirty filesystems, etc. Right; a fixup + printf is probably the correct approach, until you believe fixups are unnecessary, in which case the common developer won't be hitting the panics, it'll only be the border cases. This is why aligned access restrictions should be turned on (bit 18 in EFlags) on Intel processors that support it (486 and above). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810161956.MAA24313>