Before we disabled the warning about RWX segments only for picolibc,
but this issue is popping up on more and more toolchains (looking
at MSP430 and RISC-V). Other than on `native`/`native64`, there is no
MMU to enforce whatever permissions the segments contain anyway.
(And writing to ROM with regular store instructions will not be possible
even without the need for an MMU.)
So let's just globally disable this warning, unless building for
`native` and `native64`.
Before the build system used something like
echo "int main(){} void _exit(int n) {(void)n;while(1);}" | LC_ALL=C $(LINK) -xc - -o /dev/null -lc -Wall -Wextra -pedantic <FLAGS_TO_TEST>
to check for flags supported by the compiler (used as linker frontend).
This however no longer works with newlib 4.3.0, which requires the
symbols `_sbrk_r`, `_close_r`, `_lseek_r`, `_read_r`, and `_write_r` to
be present. Instead, now a new file `minimal_linkable.c` was added that
adds all the missing symbols and is used in the linker feature tests
instead.
Modern binutils complain about segments with RWX permissions. While
this is indeed a bad habit, RIOT ignores segments permissions anyway.
(We do have a `mpu_noexec_ram` module to disable execution of all of
RAM, which would do so regardless of the segment permission.) So for
now, we can safely just disable the warning.
This fixes:
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: warning: /home/maribu/Repos/software/RIOT/examples/default/bin/nucleo-f767zi/default.elf has a LOAD segment with RWX permissions
collect2: error: ld returned 1 exit status
The test for the requirement of disabling wchar_t size warnings assumed
that $(CC) is used for linking, instead of $(LINK). With GCC $(LINK)
and $(CC) happen to be (in most cases) identical, but with LLVM they
are not. This results in issues with compiling with LLVM.
The check for `newlib-nano` assumes that a toolchain which provides `newlib-nano` provides both the normal version and the nano version of the `newlib`.The nano version of `newlib.h` is therefore stored in its own include directory. This is the case for toolchains which allow to use both the normal and the nano version, e.g. for ARM and RISC-V.
However, if the toolchain provides `newlib_nano` but only allows the use of the nano version, it will only have the nano version of `newlib.h` and no separate directory for it, e.g. for ESP32.
To still be able to use such toolchains with `newlib_nano`, the check is changed so that the setting of the `-isystem` option depends on the existence of the separate directory.
This is a regression which was introduced in #16114, without resetting
the color the red color will be used for all following text written to
the terminal and will also cause the shell prompt etc. pp. to be colored
in red which is undesirable. This commit fixes this regression by using
the ANSI escape sequences to reset the color after the error message has
been written.
This makes RIOT use the integer-only printf/scanf code by default and
includes a new make parameter to select the full floating point
version. This saves about 6kB of text space when building hello-world
for the microbit board.
Signed-off-by: Keith Packard <keithp@keithp.com>
----
v2:
Use USEMODULE=printf_float instead of separate parameter
Support for picolibc as alternative libc implementation is added with
this commit. For now only cortex-m CPU's are supported.
Enable via PICOLIBC=1
---
v2:
squash fixes in
v3:
Remove picolibc integer printf/scanf stuff from sys/Makefile.include,
it gets set in makefiles/libc/picolibc.mk
fixup for dependency
It replaces
make BOARD=iotlab-m3 info-debug-variable-NEWLIB_INCLUDE_DIR
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/
with
make BOARD=iotlab-m3 info-debug-variable-NEWLIB_INCLUDE_DIR
/usr/arm-none-eabi/include
Without trailing slash and without relative '..' everywhere.
It also uses `realpath` instead of `abspath` to support Mingw32.
Some versions of Mingw32 abspath implementation has trouble working with
windows formatted path.
$(abspath "C:/A/B") returns "/C/CUR/DIR/C:/A/B" instead of "/C/A/B"
relpath does not have this problem, it does additional symlink resolution but is
not a problem.
Note: on windows it does not remove the trailing `/`.
https://github.com/zephyrproject-rtos/zephyr/issues/2061#issuecomment-331635063
Patched in
941059c69f
Only keep lines that are indeed include path.
It also keeps newlines as they do not matter.
It fixes Mingw32 support where `grep '^\s'` is not working the same way.
It also handles some mac `sed` that do not support `\s`.
Ouput tested with:
make -C examples/hello-world BOARD=samr21-xpro info-debug-variable-COMPILER_INCLUDE_PATHS
# by also putting newlines for readability
Now:
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include-fixed
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include
Before:
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/cc1 -E -quiet -v -iprefix /usr/bin/../lib/gcc/arm-none-eabi/7.2.1/ -isysroot /usr/bin/../arm-none-eabi -D__USES_INITFINI__ /dev/null
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include-fixed
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include
When NEWLIB_INCLUDE_DIR is set from other parts than 'COMPILER_INCLUDE_PATHS' it
does not have a trailing slash.
Also, it makes it more problematic when supplying it from the command line.
And anyway having two '/' does not break anything.
In the previous state, with llvm and arm for example, newlib-nano include dir
NEWLIB_NANO_INCLUDE_DIR is placed after NEWLIB_INCLUDES and so the default
'newlib.h' is used instead of the nano version.
