The correct way to overrride the malloc family of functions in newlib-nano is
to provide the *_r (reentrant) variants. Newlib implements the "normal"
functions on top of these (see the newlib source code). Also, internally it calls
the *_r functions when allocating buffers.
If only the "normal" non-reentrant functions are provided this will mean that
some of the code will still use the vanilla newlib allocator. Furthermore, if
one uses the whole heap as a pool for TLSF then the system may in the best case
crash as there is no enough memory for its internall allocations or in the worst
case function eratically (this depends on how the heap reserved, there is an
upcomming series of commits in that direction).
This commit splits the handling between newlib and native. It also prepares the
ground for future work on the pool initialization.
Right now I could only test this in ARM and native and I cannot ensure it will
work on other platforms. Replacing the system's memory allocator is not something
that can be taken lightly and will inevitably require diving into the depths of
the libc. Therefore I would say that using TLSF as a system wide allocator is ATM
supported officially only on those plaftorms.
Testing:
Aside from reading the newlib sources, you can see the issue in a live system
using the debugger.
Compile any example (with or without tlsf-malloc), grab a debugger and place
a breakpoint in sbrk and _sbrk_r. Doing a backtrace will reveal it gets called
by _malloc_r.
A note says "The nomips16 attribute should not really be needed,
it works around a toolchain issue in 2016.05-03."
In fact, in 2018.09-03, the attribute leads to this error:
```cpu/mips32r2_common/thread_arch.c:191:1: error: ‘_mips_handle_exception’ redeclared with conflicting ‘nomips16’ attributes```
This this commit removes the attribute.
TCP options have up to three fields (kind, length, value). The
current code only checks for the presence of the first field. Before
accessing the second field (length) the code must ensure that a length
field is even present.
This reverts commit 422644bd3a.
The option is only supported after 2.6 which is currently not the
version given with 'esp' toolchain.
It was a bit too early to switch to the new version.
Version 2.7 also supports the old option with only a warning.
This fixes the following issues:
* Use of 'realpath' not supported on mac
* Call of 'realpath' once for each file instead of one per archive
* Do not trigger 'llvm-ar' bug when invoked in the object directory.
llvm-ar rcTs ../m.a obj.o # Bugged
llvm-ar rcTs m.a m/obj.o # working
Using relative path linking is required to have a valid thin archive
path in the host when build in docker.
A received packet is outputted in DEBUG _after_ it was already parsed,
but with a reference to the already parsed header. The result is that
there can be some garbage in the output and the packet is not dumped in
total. As without parsing we do not have access to the header yet, we
use the `gnrc_netif_addr_to_str()` helper function instead of parsing
the destination address by hand.
Change shebang in script from `/bin/bash` to `/usr/bin/env bash`,
which fixed problems when `bash` is not available in standard location,
e.g., on non-Linux OSes such as FreeBSD.
