FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F13.2.0 2020-08-25T13:30:03Z 2020-08-25T13:30:03Z Alex Richardson arichardson@FreeBSD.org 2020-08-25T13:30:03Z urn:sha1:2b6ee34cf6fd3ba3a849685e0725ed69adf99748 This is needed so that setting LD/XLD is not ignored when linking with $CC instead of directly using $LD. Currently only clang accepts an absolute path for -fuse-ld= (Clang 12+ will add a new --ld-path flag), so we now warn when building with GCC and $LD != "ld" since that might result in the wrong linker being used. We have been setting XLD=/path/to/cheri/ld.lld in CheriBSD for a long time and used a similar version of this patch to avoid linking with /usr/bin/ld. This change is also required when building FreeBSD on an Ubuntu with Clang: In that case we set XCC=/usr/lib/llvm-10/bin/clang and since /usr/lib/llvm-10/bin/ does not contain a "ld" binary the build fails with `clang: error: unable to execute command: Executable "ld" doesn't exist!` unless we pass -fuse-ld=/usr/lib/llvm-10/bin/ld.lld. This change passes -fuse-ld instead of copying ${XLD} to WOLRDTMP/bin/ld since then we would have to ensure that this file does not exist while building the bootstrap tools. The cross-linker might not be compatible with the host linker (e.g. when building on macos: host-linker= Mach-O /usr/bin/ld, cross-linker=LLVM ld.lld). Reviewed By: brooks, emaste Differential Revision: https://reviews.freebsd.org/D26055 2017-03-04T10:10:17Z Enji Cooper ngie@FreeBSD.org 2017-03-04T10:10:17Z urn:sha1:193d9e768ba63fcfb187cfd17f461f7d41345048 This simplifies make output/logic Tested with: `cd sys/modules; make ALL_MODULES=` on amd64 MFC after: 1 month Sponsored by: Dell EMC Isilon 2016-08-29T07:48:35Z Ed Schouten ed@FreeBSD.org 2016-08-29T07:48:35Z urn:sha1:bab6a051ecd3474e1ccae8bc753680a51309021b 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-27T09:50:11Z Ed Schouten ed@FreeBSD.org 2016-08-27T09:50:11Z urn:sha1:fb90d86466c422b01847ef7950eb901d2262bb00 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-21T15:14:06Z Ed Schouten ed@FreeBSD.org 2016-08-21T15:14:06Z urn:sha1:4fbc90654cc14b60d67edc24bf962fe9f5dc6427 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-21T07:28:38Z Ed Schouten ed@FreeBSD.org 2016-08-21T07:28:38Z urn:sha1:7ce0716103b6d8275c8cb6d98307632db26ad82c 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-10T21:02:41Z Ed Schouten ed@FreeBSD.org 2016-08-10T21:02:41Z urn:sha1:13b4b4df987d8f05c2cd5813cfe05db953c37c9e 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 2015-10-22T09:07:53Z Ed Schouten ed@FreeBSD.org 2015-10-22T09:07:53Z urn:sha1:b78ef4bd86f5fbc328996350735aa6586cd1bc35 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-16T10:26:15Z Ed Schouten ed@FreeBSD.org 2015-10-16T10:26:15Z urn:sha1:aa40bd817ccc8fd68ceabcfcf601ad560fc3fcab MACHINE_CPUARCH expands to aarch64 for arm64, whereas MACHINE always corresponds to the directory name under sys/ that contains the sources for that architecture. 2015-07-22T07:32:49Z Ed Schouten ed@FreeBSD.org 2015-07-22T07:32:49Z urn:sha1:8bc78518035f687c789ca0c413daca97b701cfd8 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.