On Sun, Feb 05, 2006 at 02:24:52AM -0500, Ross wrote:
> The DIAGNOSTIC problem, now fixed,  was caused by the src/common
> bcopy merge, which led to a DIAGNOSTIC assertion against a bcopy
> zero destination, which caused a panic (on macppc) before console
> attachment. The old libkern bcopy allowed a 0 destination.
> 
> We might want to think about an explicit API for copies with a
> destination that aliases NULL.

As this only affects the installation of the powerpc reserved trap vector
it is better to create a powerpc-generic function to install trap vectors.

See `trap_copy()' from arch/evbppc/explora/machdep.c as an example.

Affected files (from a quick grep) are:

	arch/powerpc/ibm4xx/ibm4xx_machdep.c
	arch/powerpc/oea/oea_machdep.c
	arch/evbppc/walnut/machdep.c
	arch/evbppc/explora/machdep.c
	arch/amigappc/amigappc/machdep.c

As I only have access to `explora' I cannot test such a function.

> > From: Ross Harvey <ross@netbsd.org>
> > Subject: CVS commit: src/common/lib/libc/string
> > To: source-changes@NetBSD.org
> > Date: Sun,  5 Feb 2006 06:47:48 +0000 (UTC)
> > 
> > 
> > Module Name:    src
> > Committed By:   ross
> > Date:           Sun Feb  5 06:47:48 UTC 2006
> > 
> > Modified Files:
> >         src/common/lib/libc/string: bcopy.c
> > 
> > Log Message:
> > Don't do DIAGASSERT against NULL if _KERNEL This puts us back to
> > kernel behavior before src/common where 0 was a valid dest addr.
> > 
> > This should fix the macppc (and other OEA ppc) silent-death-on-DIAGNOSTIC
> > issue, and possibly other DIAGNOSTIC failures.
> > 
> > XXX it might be worth thinking about an API where 0 is allowed in
> > documented cases and not allowed otherwise.
> > 
> > 
> > To generate a diff of this commit:
> > cvs rdiff -r1.1 -r1.2 src/common/lib/libc/string/bcopy.c
> > 
> > Please note that diffs are not public domain; they are subject to the
> > copyright notices on the relevant files.

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)