It has come to my attention that different macros are used for
enabling profiling support.  In general it appears that userland code
uses PROF while kernel code uses GPROF.  This inconsistancy may cause
incorrect kernel profile data to be collected.

Most ports <machine/asm.h> headers use PROF, but some will accept
either.  The kernel C code uses GPROF.  

bsd.lib.mk causes PROF to be defined when compiling/assembling profile
instrumented libraries.  config -p causes GPROF to be defined when
compiling/assembling a profile instrumented kernel.  Unless the user
adds an additional -DPROF, assembly language functions in libkern and
locore probably won't be instrumented.

One quick hack would be to have config define PROF in addition to
GPROF.  A more extensive change would be to change current uses of
PROF to GPROF.

I favor the latter approach, as the profile instrumentation we emit is
for "gprof" not "prof".  If we hijack "PROF" for gprof, what should be
used if someone decides to contribute support for the traditional flat
"prof" profiling in the future.

I am interested in hearing others opinions on this subject.

	--jtc