Any problems reported by testers have been fixed, and massive
cross-compiling of kernels has shown that any problems that remain
with actually building kernels are not related to this.
- replace opt_kgdb_machdep.h with opt_kgdb.h
- defparam opt_kgdb.h:
KGDB_DEV KGDB_DEVNAME KGDB_DEVADDR KGDB_DEVRATE KGDB_DEVMODE
- move from opt_ddbparam.h to opt_ddb.h:
DDB_FROMCONSOLE DDB_ONPANIC DDB_HISTORY_SIZE DDB_BREAK_CHAR SYMTAB_SPACE
- replace KGDBDEV with KGDB_DEV
- replace KGDBADDR with KGDB_DEVADDR
- replace KGDBMODE with KGDB_DEVMODE
- replace KGDBRATE with KGDB_DEVRATE
- use `9600' instead of `0x2580' for 9600 baud rate
- use correct quotes for options KGDB_DEVNAME="\"com\""
- use correct quotes for options KGDB_DEV="17*256+0"
- remove unnecessary dependancy on Makefile for kgdb_stub.o
- minor whitespace cleanup
- Make the 32-bit SPARC profile support work with the GCC 2.95.3
SPARC ELF compiler, which uses a different name for mcount.
- Make the 64-bit SPARC profile support header look more like the 32-bit
SPARC header (no functional change -- 64-bit SPARC already used the
correct mcount name).
the etc Makefile override that by putting USETOOLS into $.MAKEOVERRIDES
This way the default for kernel compiles is still to use the installed
toolchain instead of depending on $TOOLDIR. $TOOLDIR can be used by
simply adding USETOOLS=yes to the command line as usual.
Adjust each ports template to set the default no setting and also pull in
bsd.own.mk if they weren't already to ensure they'll build correctly
with the new toolchain setup.
- Put all options necessary to build a 64-bit kernel into std.sparc64-64,
which can be included after std.sparc64.
- Change the logic used to enable 64-bit kernels. The kernel Makefile now
uses an LP64 make variable, and explicitly sets compiler flags and linker
scripts to generate 32-bit or 64-bit kernels.
If __PCI_DEV_FUNCORDER is defined, don't do the song-and-dance to check if
a device is multi-function; machdep code is going to tell us exactly which
functions to probe.
Note this required changing how pci_func_devorder() works in the
sparc64 PCI machdep code; now the "curnode" is assumed to point
to the bus, rather than some function (typically 0) on the device,
just as pci_bus_devorder() makes that assumption.
All this should allow the PCI code to actually locate the second
HME device on a Sun Netra t1, which is at 3,1 -- previously, the
PCI code would have missed it because there is no device at 3,0.
(Sun deserves a brick to the head for this one -- this seems clearly
out of line with the PCI spec.)
