d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8cd823ecf7
freebsd-dev/sys/modules/cloudabi64/Makefile

39 lines
1.1 KiB
Makefile
Raw Normal View History

Add Makefiles for CloudABI kernel modules. Place all of the machine/pointer size independent code in a kernel module called 'cloudabi'. All of the 64-bit specific code goes in a separate module called 'cloudabi64'. The latter is only enabled on amd64, as it is the only architecture supported.
2015-07-22 07:32:49 +00:00
# $FreeBSD$
sys/modules: normalize .CURDIR-relative paths to SRCTOP This simplifies make output/logic Tested with: `cd sys/modules; make ALL_MODULES=` on amd64 MFC after: 1 month Sponsored by: Dell EMC Isilon
2017-03-04 10:10:17 +00:00
SYSDIR?=${SRCTOP}/sys
Provide the CloudABI vDSO to its executables. CloudABI executables already provide support for passing in vDSOs. This functionality is used by the emulator for OS X to inject system call handlers. On FreeBSD, we could use it to optimize calls to gettimeofday(), etc. Though I don't have any plans to optimize any system calls right now, let's go ahead and already pass in a vDSO. This will allow us to simplify the executables, as the traditional "syscall" shims can be removed entirely. It also means that we gain more flexibility with regards to adding and removing system calls. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D7438
2016-08-10 21:02:41 +00:00
.PATH: ${SYSDIR}/compat/cloudabi64
Properly use MACHINE_CPUARCH for finding cloudabi*_sysvec.c. The build of the cloudabi32 kernel module currently fails for PC98. In the case of PC98, we just want to use the code for i386. Reported by: np
2016-08-27 09:50:11 +00:00
.PATH: ${SYSDIR}/${MACHINE_CPUARCH}/cloudabi64
Use both the MACHINE and MACHINE_CPUARCH directories for finding sources. When fixing this module to build on PC98, I actually broke the build on ARM64. On PC98 we need to pull in the sources from the MACHINE_CPUARCH (i386), but on ARM64 we need to use the MACHINE, as MACHINE_CPUARCH is set to aarch64 instead of just arm64.
2016-08-29 07:48:35 +00:00
.PATH: ${SYSDIR}/${MACHINE}/cloudabi64
Add Makefiles for CloudABI kernel modules. Place all of the machine/pointer size independent code in a kernel module called 'cloudabi'. All of the 64-bit specific code goes in a separate module called 'cloudabi64'. The latter is only enabled on amd64, as it is the only architecture supported.
2015-07-22 07:32:49 +00:00
KMOD= cloudabi64
Refactoring: move out generic bits from cloudabi64_sysvec.c. In order to make it easier to support CloudABI on ARM64, move out all of the bits from the AMD64 cloudabi_sysvec.c into a new file cloudabi_module.c that would otherwise remain identical. This reduces the AMD64 specific code to just ~160 lines. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D3974
2015-10-22 09:07:53 +00:00
SRCS= cloudabi64_fd.c cloudabi64_module.c cloudabi64_poll.c \
cloudabi64_sock.c cloudabi64_syscalls.c cloudabi64_sysent.c \
cloudabi64_sysvec.c cloudabi64_thread.c
Add Makefiles for CloudABI kernel modules. Place all of the machine/pointer size independent code in a kernel module called 'cloudabi'. All of the 64-bit specific code goes in a separate module called 'cloudabi64'. The latter is only enabled on amd64, as it is the only architecture supported.
2015-07-22 07:32:49 +00:00
Provide the CloudABI vDSO to its executables. CloudABI executables already provide support for passing in vDSOs. This functionality is used by the emulator for OS X to inject system call handlers. On FreeBSD, we could use it to optimize calls to gettimeofday(), etc. Though I don't have any plans to optimize any system calls right now, let's go ahead and already pass in a vDSO. This will allow us to simplify the executables, as the traditional "syscall" shims can be removed entirely. It also means that we gain more flexibility with regards to adding and removing system calls. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D7438
2016-08-10 21:02:41 +00:00
OBJS= cloudabi64_vdso_blob.o
CLEANFILES=cloudabi64_vdso.o
.if ${MACHINE_CPUARCH} == "aarch64"
Rewrite the vDSOs for CloudABI in assembly. The reason why the old vDSOs were written in C using inline assembly was purely because they were embedded in the C library directly as static inline functions. This was practical during development, because it meant you could invoke system calls without any library dependencies. The vDSO was simply a copy of these functions. Now that we require the use of the vDSO, there is no longer any need for embedding them in C code directly. Rewriting them in assembly has the advantage that they are closer to ideal (less useless branching, less assumptions about registers remaining unclobbered by the kernel, etc). They are also easier to build, as they no longer depend on the C type information for CloudABI. Obtained from: https://github.com/NuxiNL/cloudabi
2016-08-21 07:28:38 +00:00
VDSO_SRCS=${SYSDIR}/contrib/cloudabi/cloudabi_vdso_aarch64.S
Provide the CloudABI vDSO to its executables. CloudABI executables already provide support for passing in vDSOs. This functionality is used by the emulator for OS X to inject system call handlers. On FreeBSD, we could use it to optimize calls to gettimeofday(), etc. Though I don't have any plans to optimize any system calls right now, let's go ahead and already pass in a vDSO. This will allow us to simplify the executables, as the traditional "syscall" shims can be removed entirely. It also means that we gain more flexibility with regards to adding and removing system calls. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D7438
2016-08-10 21:02:41 +00:00
OUTPUT_TARGET=elf64-littleaarch64
BINARY_ARCHITECTURE=aarch64
.elif ${MACHINE_CPUARCH} == "amd64"
Rewrite the vDSOs for CloudABI in assembly. The reason why the old vDSOs were written in C using inline assembly was purely because they were embedded in the C library directly as static inline functions. This was practical during development, because it meant you could invoke system calls without any library dependencies. The vDSO was simply a copy of these functions. Now that we require the use of the vDSO, there is no longer any need for embedding them in C code directly. Rewriting them in assembly has the advantage that they are closer to ideal (less useless branching, less assumptions about registers remaining unclobbered by the kernel, etc). They are also easier to build, as they no longer depend on the C type information for CloudABI. Obtained from: https://github.com/NuxiNL/cloudabi
2016-08-21 07:28:38 +00:00
VDSO_SRCS=${SYSDIR}/contrib/cloudabi/cloudabi_vdso_x86_64.S
Provide the CloudABI vDSO to its executables. CloudABI executables already provide support for passing in vDSOs. This functionality is used by the emulator for OS X to inject system call handlers. On FreeBSD, we could use it to optimize calls to gettimeofday(), etc. Though I don't have any plans to optimize any system calls right now, let's go ahead and already pass in a vDSO. This will allow us to simplify the executables, as the traditional "syscall" shims can be removed entirely. It also means that we gain more flexibility with regards to adding and removing system calls. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D7438
2016-08-10 21:02:41 +00:00
OUTPUT_TARGET=elf64-x86-64-freebsd
BINARY_ARCHITECTURE=i386
.endif
cloudabi64_vdso.o: ${VDSO_SRCS}
Rewrite the vDSOs for CloudABI in assembly. The reason why the old vDSOs were written in C using inline assembly was purely because they were embedded in the C library directly as static inline functions. This was practical during development, because it meant you could invoke system calls without any library dependencies. The vDSO was simply a copy of these functions. Now that we require the use of the vDSO, there is no longer any need for embedding them in C code directly. Rewriting them in assembly has the advantage that they are closer to ideal (less useless branching, less assumptions about registers remaining unclobbered by the kernel, etc). They are also easier to build, as they no longer depend on the C type information for CloudABI. Obtained from: https://github.com/NuxiNL/cloudabi
2016-08-21 07:28:38 +00:00
${CC} -x assembler-with-cpp -shared -nostdinc -nostdlib \
Move the linker script from cloudabi64/ to cloudabi/. It turns out that it works perfectly fine for generating 32-bits vDSOs as well. While there, get rid of the extraneous .s file extension.
2016-08-21 15:14:06 +00:00
-Wl,-T${SYSDIR}/compat/cloudabi/cloudabi_vdso.lds \
Provide the CloudABI vDSO to its executables. CloudABI executables already provide support for passing in vDSOs. This functionality is used by the emulator for OS X to inject system call handlers. On FreeBSD, we could use it to optimize calls to gettimeofday(), etc. Though I don't have any plans to optimize any system calls right now, let's go ahead and already pass in a vDSO. This will allow us to simplify the executables, as the traditional "syscall" shims can be removed entirely. It also means that we gain more flexibility with regards to adding and removing system calls. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D7438
2016-08-10 21:02:41 +00:00
${VDSO_SRCS} -o ${.TARGET}
cloudabi64_vdso_blob.o: cloudabi64_vdso.o
${OBJCOPY} --input-target binary \
--output-target ${OUTPUT_TARGET} \
--binary-architecture ${BINARY_ARCHITECTURE} \
cloudabi64_vdso.o ${.TARGET}
Add Makefiles for CloudABI kernel modules. Place all of the machine/pointer size independent code in a kernel module called 'cloudabi'. All of the 64-bit specific code goes in a separate module called 'cloudabi64'. The latter is only enabled on amd64, as it is the only architecture supported.
2015-07-22 07:32:49 +00:00
.include <bsd.kmod.mk>
Reference in New Issue Copy Permalink