List non-default asm sources in MDASM so that they replace the defaults.
For funny or incomplete syscalls, list them in NOASM to stop them
from getting built as defaults.
Include the architecture specific sys makefile like previously, but
what this contains differs. It defines MDASM which list architecture
specific asm code that *replaces* syscalls of the same name defined
in MIASM (which gets defined by the syscall.mk or netbsd_syscall.mk
dependent of NETBSD_SYSCALLS being defined). If a syscall has a
C source implementation or something funny done to it, or just doesn't
need default asm source generated for it, then it is listed in NOASM.
syscall.mk is generated by makesyscalls.sh with other syscall files.
netbsd_syscall.mk is a hand-generated equivalent. So if a new syscall
is added and no other makefiles are edited, it will automatically have
the default asm source generated for it (whether you want it or not).
Anything listed in MDASM gets added to SRCS and gets built. For
each syscall name in MIASM, if it doesn't exist in MDASM or NOASM,
it gets added to the ASM or ASMR lists to have code generated for it.
If the syscall name was listed in HIDDEN_SYSCALLS (intended for use
by libc_r, not libc which has it defined, but empty), then the name
is added to the ASMR list and gets renamed before being built;
otherwise it is added to the ASM list and gets built with the same
name.
I wonder if this is too complicated. But it works on both i386 and alpha.
substitution errors for variables that don't exist.
If a machine architecture dependent makefile exists, include it
to discover if libc or libc_r is being built with NetBSD syscalls
instead of FreeBSD ones.
Put a NO_QUAD thingy around the quad makefile so that 64-bit
architectures can ignore that sh*t.
In the test for MDSRCS being empty, add all MISRCS to SRCS, rather
than just ignoring them.
Define the HIDDEN_SYSCALLS macro as empty because libc doesn't have
renamed syscalls. This avoids an undefined macro error when
libc/sys/Makefile.inc goes to look though it. HIDDEN_SYSCALLS is
used by the equivalent makefile to this one in lib/libc_r to list
those syscalls that it needs to rename so that libc_r can provide
replacement functions.
(and even run). These files don't necessarily make sense for a
FreeBSD/Alpha kernel build. That will come later and these files
will be changed accordingly.
Change MACHINE references to MACHINE_ARCH.
Declare the names of the syscalls that need to be renamed to allow
for the functions that libc_r provides replacements for. This list
used to be in lib/libc/sys/Makefile.inc, but has been moved here
to keep that makefile tidy and remove the temptation for people to
add things to the list without adding a libc_r replacement function.
prototypes for the spinlock functions that will be used for thread locks.
libc will have stubs declared with weak symbols. libpthread and libc_r
will have functions that really do something.
the other syscall files are generated into. This new file is to be
included by src/lib/libc/sys/Makefile.inc to automatically pick up
syscall names.
The other file, netbsd_syscall.mk, is the hand-generated NetBSD
equivalent to be included by src/lib/libc/sys/Makefile.inc when
_NETBSD_SYSCALLS is defined during the build of libc/libc_r.
during the libc/libc_r to automatically pick up syscall names on
the assumption that default asm code needs to generated for them.
In the up-coming changes to the libc makefiles, there is the option
to provide a machine dependent asm source file which will turn off
the automatic generation of the default. There is also an option
to just stop code being generated for a syscall. In most cases,
though, the default asm code is all that is required, so this
change makes that the most convenient was to do business.
Idea suggested by: bde
objdump all build out of the FreeBSD tree. At EDS we used to call this
a "significant emotional event".
Still using the lorder script from NetBSD until I can explain why the
is a difference in nm behaviour when the output looks the same.
Changed MACHINE to MACHINE_ARCH with the expectation that pc98 will
use elf the same as i386.
Nuked tahoe and vax 'cause the files they reference aren't in the
tree. If you want vax goto NetBSD. If you want tahoe... tough.
