Pass -fuse-ld=/path/to/ld if ${LD} != "ld"This is needed so that setting LD/XLD is not ignored when linking with $CCinstead of directly using $LD. Currently only clang accepts an absolutepath for
Pass -fuse-ld=/path/to/ld if ${LD} != "ld"This is needed so that setting LD/XLD is not ignored when linking with $CCinstead of directly using $LD. Currently only clang accepts an absolutepath for -fuse-ld= (Clang 12+ will add a new --ld-path flag), so we nowwarn when building with GCC and $LD != "ld" since that might result in thewrong linker being used.We have been setting XLD=/path/to/cheri/ld.lld in CheriBSD for a long time andused 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/ldsince then we would have to ensure that this file does not exist whilebuilding the bootstrap tools. The cross-linker might not be compatible withthe host linker (e.g. when building on macos: host-linker= Mach-O /usr/bin/ld,cross-linker=LLVM ld.lld).Reviewed By: brooks, emasteDifferential Revision: https://reviews.freebsd.org/D26055
show more ...
sys/modules: normalize .CURDIR-relative paths to SRCTOPThis simplifies make output/logicTested with: `cd sys/modules; make ALL_MODULES=` on amd64MFC after: 1 monthSponsored by: Dell EMC Isilon
Use both the MACHINE and MACHINE_CPUARCH directories for finding sources.When fixing this module to build on PC98, I actually broke the build onARM64. On PC98 we need to pull in the sources from t
Use both the MACHINE and MACHINE_CPUARCH directories for finding sources.When fixing this module to build on PC98, I actually broke the build onARM64. 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 isset to aarch64 instead of just arm64.
Properly use MACHINE_CPUARCH for finding cloudabi*_sysvec.c.The build of the cloudabi32 kernel module currently fails for PC98. Inthe case of PC98, we just want to use the code for i386.Reported
Properly use MACHINE_CPUARCH for finding cloudabi*_sysvec.c.The build of the cloudabi32 kernel module currently fails for PC98. Inthe case of PC98, we just want to use the code for i386.Reported by: np
Move the linker script from cloudabi64/ to cloudabi/.It turns out that it works perfectly fine for generating 32-bits vDSOsas well. While there, get rid of the extraneous .s file extension.
Rewrite the vDSOs for CloudABI in assembly.The reason why the old vDSOs were written in C using inline assembly waspurely because they were embedded in the C library directly as staticinline func
Rewrite the vDSOs for CloudABI in assembly.The reason why the old vDSOs were written in C using inline assembly waspurely because they were embedded in the C library directly as staticinline functions. This was practical during development, because itmeant 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 forembedding them in C code directly. Rewriting them in assembly has theadvantage that they are closer to ideal (less useless branching, lessassumptions about registers remaining unclobbered by the kernel, etc).They are also easier to build, as they no longer depend on the C typeinformation for CloudABI.Obtained from: https://github.com/NuxiNL/cloudabi
Provide the CloudABI vDSO to its executables.CloudABI executables already provide support for passing in vDSOs. Thisfunctionality is used by the emulator for OS X to inject system callhandlers. O
Provide the CloudABI vDSO to its executables.CloudABI executables already provide support for passing in vDSOs. Thisfunctionality is used by the emulator for OS X to inject system callhandlers. On FreeBSD, we could use it to optimize calls togettimeofday(), 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 tosimplify the executables, as the traditional "syscall" shims can beremoved entirely. It also means that we gain more flexibility withregards to adding and removing system calls.Reviewed by: kibDifferential Revision: https://reviews.freebsd.org/D7438
Refactoring: move out generic bits from cloudabi64_sysvec.c.In order to make it easier to support CloudABI on ARM64, move out all ofthe bits from the AMD64 cloudabi_sysvec.c into a new fileclouda
Refactoring: move out generic bits from cloudabi64_sysvec.c.In order to make it easier to support CloudABI on ARM64, move out all ofthe bits from the AMD64 cloudabi_sysvec.c into a new filecloudabi_module.c that would otherwise remain identical. This reducesthe AMD64 specific code to just ~160 lines.Reviewed by: kibDifferential Revision: https://reviews.freebsd.org/D3974
Use the right variable name.MACHINE_CPUARCH expands to aarch64 for arm64, whereas MACHINE alwayscorresponds to the directory name under sys/ that contains the sourcesfor that architecture.
Add Makefiles for CloudABI kernel modules.Place all of the machine/pointer size independent code in a kernelmodule called 'cloudabi'. All of the 64-bit specific code goes in aseparate module call
Add Makefiles for CloudABI kernel modules.Place all of the machine/pointer size independent code in a kernelmodule called 'cloudabi'. All of the 64-bit specific code goes in aseparate module called 'cloudabi64'. The latter is only enabled onamd64, as it is the only architecture supported.