Designated initializers make the code much more readable and are part
of the C standard since C99. C++ with C++20 finally caught up.
Until we switch to that C++ version, let's disable the annoying
warning rather than reducing the code quality for the sake of
strict C++ compatibility of our headers.
With GCC, the C++ compiler knows all builtin C include paths *and*
all builtin C++ include paths, but the C compiler only knows the
C include paths. Hence, let's use the C++ compiler to collect
the include paths.
The `--param=min-pagesize=0` needed since GCC 12 is still needed with
GCC 13. This time at least the message is more meaningful:
note: source object is likely at address zero
This is something that is not expected in a userspace app, but with
bare metal MCUs and often flash or memory mapped I/O starting from
address zero, this warning prevents legitimate code from compiling.
GCC 12 gives out of bounds warnings when the resulting address is out
of bounds of what GCC assumes to be the valid address space. It seems
that by default the address 0x0 is not considered valid (which would
be a NULL pointer and typically not mapped in a userspace behind an MMU
scenario), but in fact is valid on bare metal hardware. At least on
AVR and MSP430 this needs to be set. On many Cortex M MCUs 0x0 is also
a valid address (e.g. often the flash is mapped there), but seemingly
for them `--param=min-pagesize=0` is already the default. In any case,
it won't hurt to set it explicit for them as well.
With b30efeeb65 a warning was introduced when using `make term` without
the proper toolchain installed (e.g. when using BUILD_IN_DOCKER, but
`term` outside of the docker). This removes this warning
When trying to compile `examples/hello-world` on my 465 MHz Mendocino
I got
/home/benpicco/dev/RIOT/makefiles/toolchain/gnu.inc.mk:29: extraneous text after 'ifneq' directive
Turns out the version of `make` on Archlinux32 is newer than that in
Ubuntu 22.04, which somehow ignored the extra parenthesis.
Turns out this (t)rusty old machine is still good for writing patches :D
clang/LLVM is a bit more finicky with what target triples it accepts compared
to GCC. However, the GCC target triple is needed to properly locate the C
libraries. In case a locally installed GCC toolchain uses a technically not
fully correct target triple, it might be impossible to build with LLVM.
The solution here is to allow specifying a TARGET_ARCH_LLVM target triple
(which defaults to TARGET_ARCH), which is passed to clang. For locating the
C lib, still TARGET_ARCH is used.
`-Watomic-alignment` warns when C11 atomics have to be implemented via a to one
of the functions in `core/atomic_c11.c`. Unlike to the context of Desktop or
Server class machines, the performance penalty of this calls is insignificant
(and not existing with LTO). So this is not an issue in our context.
On the other hand: Keeping `-Watomic-alignment` prevents building applications
using C11 atomics on all platforms the atomic operations are not implemented
without calls to `core/atomic_c11.c` (due to `-Werror`), reducing portability.
So not only does the warning is not useful in our context, it actually prevents
portable use of C11 atomics. It is the most sensible thing to just disable it.
When '$(PREFIX)objdump' is not present fallback to native '(g)objdump'.
'objdump' is used when flashing for some boards but the toolchain may
not be installed when building in docker.
This will allow using 'objdump' in 'cpu/kinetis/dist/check-fcfield.sh'.
`command -v first second third` only works in `bash` and not in `sh`.
So replace with multiple calls to `command`.
This fixes using `objcopy` when the toolchain `objcopy` is not available.
This completely removes the hardcoded/os specific path setting for includes.
It directly queries gcc include directories.
It takes what was already done by `makefiles/libc/llvm.inc.mk`.
I replaced the `GCC_MULTI_DIR` handling by givining `CFLAGS_CPU` when
searching for include directories.
`CFLAGS` cannot be used as it will crash when `-target $(CPU_ARCH)` is
added.
It currently requires using deferred variables as `CFLAGS_CPU` can be
overwritten later in the build process.
This variable can be used to specify the linker which should be used to
link C++ object files. This is needed in order to use g++ for linking
with TOOLCHAIN=llvm.
- Merge flash and flash-elf commands since they were identical except
for the file name of the image
- Split GDB command from DBG environment variable to allow more easily
configure front-ends for GDB via environment variables.
- Remove verbose tests of empty variables and replace by `: ${VAR:=default}`
- Remove passed command line arguments to sub-functions, they were
unused in the functions anyway.
- Remove TUI variable, use `export DBG_EXTRA_FLAGS=-tui` to get the same
result.
