The test inside riscv/rules.mk was assuming gcc and that the CC variable
isn't passed in from the user. This is not a very clean solution and
acts like a bandaid over the problem. Added some todos for a potential
solution.
Clean up make targets list-arch and list-toolchain to be much faster and
work without needing to invoke the archtecture's arch rules.mk. This
should make it work on machines that do not have that particular
toolchain in the path.
This is setting up for using it in the github action script.
Was already added to arm64, but arch/arm hadn't picked up this feature
yet. Uncovered a few places here or there that wasn't marking code as
float/no-float, but this fixes a problem where newer compilers are
starting to sneak in vector code because they can.
Issue #406
This reverts commit 37c3228443.
Decided it's probably not worth maintaining this and simply removed this
particular build combination (clang 13 + riscv) from the build matrix.
When building with clang-13 the zba riscv extension triggers a build
failure unless this switch is set. Set it for now, though it appears to
not be necessary for clang 14 and above.
TODO: add a version check for clang for a series of switches set based
on version in engine.mk.
Certain projects may want to prevent the usage of certain modules from
being used. Here are two examples of when this may occur:
1. The Project has it's own fdt library and does not want developer's
using the version of libfdt included with LK
2. The project does not want developers using mincrypt.
`DENY_MODULES` is a list which developers can set in their own project
makefiles which is checked on each module inclusion. If that module is
on the deny list, it causes a build failure.
When building with clang -mcmodel=medany and linking with ld.lld, we get
out-of-range relocation errors for undefined __start_<section> symbols
since 0 cannot be represented as a PC-relative offset). This is not a
problem with ld.bfd since ld.bfd rewrites the instructions to avoid the
out-of-range PC-relative relocation. For now, the simplest workaround is
to build with -fpie -mcmodel=medany (thus indirecting these symbols via
the GOT). This will be done automatically once clang includes
https://reviews.llvm.org/D107280.
Without this change I get the following linker errors:
ld.lld: error: dev/driver.c:21:(.text+0x1E): relocation R_RISCV_PCREL_HI20 out of range: -524295 is not in [-524288, 524287]; references __start_devices
See https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/126 and
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/201.
We have to compile RISC-V code with -mno-relax when linking with ld.lld
since ld.lld does not yet support RISC-V linker relaxations. Without this
change, linking with ld.lld results in many errors such as:
`relocation R_RISCV_ALIGN requires unimplemented linker relaxation`.
This support was implemented as part of LLVM 15, but to support older
versions of ld.lld we add the flag unconditionally for now.
We should build with -ffreestanding since we are building an OS kernel and
cannot rely on all hosted environment functionality being present.
Specifically this fixes a compilation error with clang caused by the
the #include_next <limits.h>:
```
In file included from target/pc-x86/config.c:9:
In file included from dev/include/dev/driver.h:10:
In file included from lib/libc/include/sys/types.h:10:
In file included from lib/libc/include/limits.h:5:
In file included from /usr/lib/llvm-15/lib/clang/15.0.7/include/limits.h:21:
/usr/include/limits.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
#include <bits/libc-header-start.h>
```
The flag fixes this issue by ensuring that __STDC_HOSTED__ is no longer set
to 1, so Clang's limits.h will not try to include the host system one.
CC, LD, etc was already settable by the environment, but not by
local.mk, since they were assigned in engine.mk as :=. Change the set to
be conditional to fix this.
Clang incorrectly diagnoses msr operations as need a 64-bit operand even
if the underlying register is actually 32 bits. Silence this warning.
There are quite a few occurrences of this warning so I opted to add the
-Wno-flag instead of wrapping all callsites in
`#pragma clang diagnostic ignored -Wasm-operand-widths`.
Currently, clang does not support the -Wno-nonnull-compare and
-Wmaybe-uninitialized warning flags so this adds lots of unknown warning
flag output for each compile job when not using GCC.
This commit adds a makefile macro to check for supported warning flags
and only adds them if the compiler actually supports them.
Add an UBSAN implementation and a new UBSAN switch to the make build.
The implementation is taken from Onyx and handles most of the cases
that should be needed for a kernel build. Floating point and fancy
C++ CFI features are not supported yet.
To build with UBSAN, pass UBSAN=1 to make such as:
PROJECT=pc-x86-64-test make -jN UBSAN=1
This allows you to tag your build dirs with an optional string.
Update scripts/buildall to also allow building all release (DEBUG=0)
builds. Add a few other convenience switches.
Based on building with --warn-undefined-variables, find a few places in
the build system where undefined variables were used incorrectly, or
never set due to unused code.
Have the arch define additional compiler flags to explicit support or
not support a floating point unit.
Add ability for modules to per file or for the whole module mark code
as needing floating point support.
Add default flags for arm64, riscv, and x86 toolchains.
Needed because gcc 12 is getting much more aggressive about using vector
instructions for non float code, so getting away with avoiding it was
no longer working.
Still not perfect: printf code is being compiled with float, so it's
possible to use floating point instructions inside core kernel or
interrupt handling code if a printf is used.
Possibly will have problems on architectures where mixing float and non
float code at the linker generates issues, but so far seems to be okay.
This is a useful warning to have on, but keep it off for now since there
are a ton of warnings here, and probably in external projects that use
LK.
CLs incoming to fix the most egregious warning violations this uncovers.
list-arch and list-toolchain will compute and print the architecture and
toolchain needed to build the project the build is set to.
Used by the CI builder to decide what toolchain to grab.
Currently EXTRA_BUILDDEPS is evaluated before build.mk. This means that
userspace apps or other EXTRA_BUILDRULES cannot add items to
EXTRA_BUILDDEPS and have it function as would be expected.
Bug: 143636864
Change-Id: Idc1504b09f31b4c54148bb6892193d11f45e08ff
From working with -Wpacked its clear that some of the virtio
structures are overly packed and result in bad codegen on particular
architectures such as riscv. Roll back from using packed but
statically assert that the sizes are correct for some future arch
where things naturally pack differently.
Mostly just a few warnings where things are promoted via passing floats to
printf. Those we should generally remove anyway because they're just
benchmarking code. Most things LK runs on either doesn't have float or
doesn't have double sized floats.
Been carrying this flag around for years but from sleuthing around in
the compiler it seems to only exist as the opposite to -fno-inline which
has an actual effect. Only reason -finline would do anything would be to
cancel a previous -fno-inline switch.
Most of the warnings are new, such as needing to mark fallthroughs on
cases explicitly. A few are based on signed vs unsigned comparisons.
Disable one warning that was annoying about comparing null to arguments
marked nonnull.
When lib/version was included, a rule depended on .PHONY. This would
unexpectedly invoke other rules defined as dependent on .PHONY (standard
phony-ness signal).
As a side effect, this used to generate srcfiles.txt and
include_paths.txt in build dir. Since they are useful, we might always
build those anyway, and not make them phony at all.
If some included rule.mk defines an additional make target that the user
might want to call (e.g., "flash"), and user specifies a project name on
the command line, then previously the outer "makefile" would call
engine.mk multiple times. The new logic prevents that.
Additionally, silence extra "Nothing to be done" messages when calling
engine.mk again after removing the project name from make goals.
This allows for individual modules to extend the main linker script,
primarily to add their own sections to interate over.
Remove the main shared_* linker scripts.
Move statement that sets DEPS make variable a bit later in engine.mk
execution flow (after including make/build.mk) so that it would include
modules added through EXTRA_BUILDRULES mechanism.
Change-Id: I5c7a02eaf272f009a81ac9868f378b9baa23faae
