Pass -fuse-ld=/path/to/ld if ${LD} != "ld"

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

Pass -fuse-ld=/path/to/ld if ${LD} != "ld"

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

show more ...

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

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 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 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.

show more ...

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

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

show more ...

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.

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 func

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

show more ...

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. O

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

show more ...

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
clouda

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

show more ...

Use the right variable name.

MACHINE_CPUARCH expands to aarch64 for arm64, whereas MACHINE always
corresponds to the directory name under sys/ that contains the sources
for that architecture.

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 call

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.

show more ...