The only reason why it is tough for us to use nano malloc
is because of the small shortcoming where nano_malloc()
splits a bigger chunk from the free list into two pieces
while handing back the second one (the tail) to the user.
This is error prone and especially bad for smaller heaps,
where nano malloc is supposed to be superior. The normal
malloc doesn't have this issue and we need to use it even
though it costs us ~2k bytes compared to nano-malloc.
The problem arise especially after giving back _every_
malloced memory to the heap and then starting to exercise
the heap again by allocating something small. This small
item might split the whole heap in two equally big parts
depending on how the heap has been exercised before.
I have uploaded the smallest possible application
(only tested on ST and Nordic devices) to show the issue
while the real customer applications are far more complicated:
https://drive.google.com/file/d/1kfSC2KOm3Os3mI7EBd-U0j63qVs8xMbt/view?usp=sharing
The application works like the following pseudo code,
where we assume a heap of 100 bytes
(I haven't taken padding and other nitty and gritty
details into account. Everything to simplify understanding):
void *ptr = malloc(52); // We get 52 bytes and we have
// 48 bytes to use.
free(ptr); // Hand back the 52 bytes to nano_malloc
// This is the magic line that shows the issue of
// nano_malloc
ptr = malloc(1); // Nano malloc will split the 52 bytes
// in the free list and hand you a pointer
// somewhere in the
// middle of the heap.
ptr2 = malloc(52); // Out of memory...
I have done a fix which hands back the first part of the
splitted chunk. Once this is fixed we obviously
have the 1 byte placed in position 0 of the heap instead
of somewhere in the middle.
However, this won't let us malloc 52 new bytes even though
we potentially have 99 bytes left to use in the heap. The
reason is that when we try to do the allocation,
nano-malloc looks into the free list and sees a 51 byte
chunk to be used.
This is not big enough so nano-malloc decides to call
sbrk for _another_ 52 bytes which is not possible since
there is only 48 bytes left to ask for.
The solution for this problem is to check if the last
item in the free list is adjacent to sbrk(0). If it is,
as it is in this case, we can just ask sbrk for the
remainder of what is needed. In this case 1 byte.
NB! I have only tested the solution on our ST device.
Use the more official fesetenv(FE_DFL_ENV) from _dll_crt0, thus
allowing to drop the _feinitialise declaration from fenv.h.
Provide a no-op _feinitialise in Cygwin as exportable symbol for really
old applications when _feinitialise was called from mainCRTStartup in
crt0.o.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Drop the Cygwin-specific fenv.cc and fenv.h file and use the equivalent
newlib functionality now, so we have at least one example of a user for
this new mechanism.
fenv.c: allow _feinitialise to be called from Cygwin startup code
fenv.h: add declarations for fegetprec and fesetprec for Cygwin only.
Fix a comment.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far the build mechanism in newlib only allowed to either define
machine-specific headers, or headers shared between all machines.
In some cases, architectures are sufficiently alike to share header
files between them, but not with other architectures. A good example
is ix86 vs. x86_64, which share certain traits with each other, but
not with other architectures.
Introduce a new configure variable called "shared_machine_dir". This
dir can then be used for headers shared between architectures.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Without this, for a bare-iron/simulator target such as cris-elf,
you'll see, at newlib build time:
/x/gccobj/./gcc/xgcc -B/x/gccobj/./gcc/ <many options elided> -c -o lib_a-aligned_alloc.o \
`test -f 'aligned_alloc.c' || echo '/y/newlib/libc/stdlib/'`aligned_alloc.c
/y/newlib/libc/stdlib/aligned_alloc.c: In function 'aligned_alloc':
/y/newlib/libc/stdlib/aligned_alloc.c:35:10: warning: implicit declaration of function \
'_memalign_r' [-Wimplicit-function-declaration]
35 | return _memalign_r (_REENT, align, size);
| ^~~~~~~~~~~
The revert-part of the revert-and-fix commit, b99887c4283f a.k.a.
"Revert previous change to sys/stat.h and fix cris libgloss",
apparently intending to revert f75aa6785151 a.k.a. "Fix regression in
cris-elf caused by sys/stat.h change" and fix it in another way,
wasn't complete. Although the fix-part added the prerequisite "#undef
st_atime" (et al) to gensyscalls, the revert-part didn't revert the
"&& !defined(__cris__)" in sys/stat.h, stopping st_atime (et al) from
being defined.
The effect of the unreverted change is that accessing the struct stat
compatibility member names "st_atime" (et al) as in "struct stat
mystat; mystat.st_atime;" yields errors, observable for example when
building libgfortran in gcc:
/x/gcc/libgfortran/intrinsics/stat.c:114:42: error: 'struct stat' has \
no member named 'st_atime'; did you mean 'st_atim'?
114 | sarray->base_addr[8 * stride] = sb.st_atime;
| ^~~~~~~~
| st_atim
(etc.)
Trivially fixed by completing the reversion, removing the "&&
!defined(__cris__)" in sys/stat.h.
Beware: the net effect of the earlier related change to struct stat in
sys/stat.h, leading up to the fix, *does* change its definition as a
type. Thankfully, replacing members like "time_t st_atime; long
st_spare1;" by "struct timespec st_atim;", ditto st_mtim and st_ctim,
is layout-compatible. To wit, that change is "binary compatible".
Incidentally, related to the simulator / Linux ABI, there's a
transitional stage (see gensyscalls), reloading between "struct stat"
(sys/stat.h) and "struct new_stat" (kernel/simulator) as necessary.
Tested by a cris-elf gcc build (including libgfortran).
This Patch removes Soft Float code from MIPS.
Instead It adds the soft float code from RISCV
The code came from FreeBSD and assumes the FreeBSD softfp
implementation not the one with GCC. That was an overlooked and
fixed in the other fenv code already.
Signed-off-by: Eshan Dhawan <eshandhawan51@gmail.com>
Change the prototypes to be in line with POSIX/glibc. This may fix
issues with new warnings produced by GCC 11.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Add the POSIX header file <poll.h> which is used by the GCC 11 Ada
runtime support.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
The Cortex-R52 processor is an Armv8-R processor with a NEON unit. This
fix prevents conflicting architecture profiles A/R errors issued by the
linker.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
The overflow check in mEMALIGn erroneously checks for INT_MAX,
albeit the input parameter is size_t. Fix this to check for
__SIZE_MAX__ instead. Also, it misses to check the req against
adding the alignment before calling mALLOc.
While at it, add out-of-bounds checks to pvALLOc, nano_memalign,
nano_valloc, and Cygwin's (unused) dlpvalloc.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
to rb parent pointers. Define RB_SWAP_CHILD to replace the child of a parent
with its twin, and use it in 4 places. Use RB_SET in rb_link_node to remove the
only linuxkpi reference to color, and then drop color- and parent-related
definitions that are defined and used only in rbtree.h.
This is intended to be entirely cosmetic, with no impact on program
behavior, and leave RB_PARENT and RB_SET_PARENT as the only ways to
read and write rb parent pointers.
Reviewed by: markj, kib
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D25264
the sibling of the root of the too-short tree is black and at least one of the
children of that sibling is red, either one or two rotations finish the
rebalancing. In the case when both of the children are red, the current
implementation uses two rotations where only one is necessary. This change
removes that extra rotation, and in that case also removes a needless
black-to-red-to-black recoloring.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D25335
without using their interfaces, making them break when the representation
changes. Revert changes that eliminated the color field from rb-trees, leaving
everything as it was before.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D25250
a bit of DIAGNOSTIC code that depends on it.
Reported by: rpokala, mjguzik
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D25204
field. Set the least significant bit in the pointer to the node from its parent
to indicate that the node is red. Have the tree rotation macros leave the
old-parent/new-child node red and the new-parent/old-child node black.
This change makes RB_LEFT and RB_RIGHT no longer assignable, and
RB_COLOR no longer defined. Any code that modifies the tree or
examines a node color would have to be modified after this change.
Reviewed by: markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D25105
where the pointer checked is provably never null. Restructure the surrounding
code just enough to make the non-nullness obvious.
Reviewed by: markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D25089
child is red or child is null. In the first case, RB_REMOVE_COLOR just changes
the child to black and returns. With this change, RB_REMOVE handles that case,
and drops the child argument to RB_REMOVE_COLOR, since that value is always
null.
RB_REMOVE_COLOR is changed to remove a couple of unneeded tests, and
to eliminate some deep indentation.
RB_ISRED is defined to combine a null check with a test for redness,
to replace that combination in several places.
Reviewed by: markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D25032
search to find the node to replace the one being removed, restructure to first
remove the replacement node and correct the parent pointers around it, and then
let the all-cases code at the end deal with the parent of the deleted node,
making it point to the replacement node. This removes one or two conditional
branches.
Reviewed by: markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D24845
macros so that is invoked at the root of every subtree that changes in an
insert or delete, and only once, and ordered from the bottom of the tree to the
top. For intel_gas.c, the only user of RB_AUGMENT I can find, change the
augmenting routine so that it does not climb from entry to tree root on every
call, and remove a 'tree correcting' function that can be supplanted by proper
tree augmentation.
Reviewed by: kib
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D23189
removing a node and reinserting it back with an updated key.
This is one of dependencies for the upcoming stats(3) code.
Reviewed by: cem
Obtained from: Netflix
MFC after: 2 weeks
Sponsored by: Klara Inc, Netflix
Differential Revision: https://reviews.freebsd.org/D21786
For configurations without x2APIC support (guests, older hardware), the global
LAPIC MMIO mapping will trigger false-positive KCSan reports as it will appear
that multiple CPUs are concurrently reading and writing the same address.
This isn't actually true, as the underlying physical access will be performed
on the local CPU's APIC. Additionally, because LAPIC access can happen during
event timer configuration, the resulting KCSan printf can produce a panic due
to attempted recursion on event timer resources.
Add a __nosanitizethread preprocessor define to prevent the compiler from
inserting TSan hooks, and apply it to the x86 LAPIC accessors.
PR: 249149
Reported by: gbe
Reviewed by: andrew, kib
Tested by: gbe
Differential Revision: https://reviews.freebsd.org/D26354
This is an unfortunate instance where the __has_attribute check does
not function usefully. Gcc does have the attribute, but for gcc it only
applies to functions, not variables, and trying to apply it to a
variable generates Wattribute. So far we only apply the attribute to
variables. Only enable the attribute for clang, for now.
Reviewed by: Anton Rang <rang at acm.org>
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22875
The assumptions of linker_set don't play nicely with
AddressSanitizer. AddressSanitizer adds a 'redzone' of zeros around
globals (including those in named sections), whereas linker_set
assumes they are all packed consecutively like a pointer array. So:
let's annotate linker_set so that AddressSanitizer ignores it.
Submitted by: Matthew Bryan <matthew.bryan@isilon.com>
Reviewed by: kib, rang_acm.org
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22239
The <sys/cdefs.h> and <stdatomic.h> headers already included support for
C11 atomics via intrinsincs in modern versions of GCC, but these versions
tried to "hide" atomic variables inside a wrapper structure. This wrapper
is not compatible with GCC's internal <stdatomic.h> header, so that if
GCC's <stdatomic.h> was used together with <sys/cdefs.h>, use of C11
atomics would fail to compile. Fix this by not hiding atomic variables
in a structure for modern versions of GCC. The headers already avoid
using a wrapper structure on clang.
Note that this wrapper was only used if C11 was not enabled (e.g.
via -std=c99), so this also fixes compile failures if a modern version
of GCC was used with -std=c11 but with FreeBSD's <stdatomic.h> instead
of GCC's <stdatomic.h> and this change fixes that case as well.
Reported by: Mark Millard
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D16585
As discussed in GCC bug 97088
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088), parameters in
prototypes of library functions should use reserved names, or no name
at all.
This patch moves the internal struct __tzrule_struct to its own
internal header sys/_tz_structs.h. This is included from newlib's
time code as well as from Cygwin's localtime wrapper.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
As discussed in GCC bug 97088
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088), parameters in
prototypes of library functions should use reserved names, or no name
at all.
This patch removes the 'ptr' parameter name from
wint_t _getwchar_r (struct _reent *);
wint_t _getwchar_unlocked_r (struct _reent *);
to avoid possible clashes with user code in case someone uses
before including Newlib's wchar.h (or uses some other conflicting
definition)
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
As discussed in GCC bug 97088
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088), parameters in
prototypes of library functions should use reserved names, or no name
at all.
This patch removes the 'j' parameter name from
extern intmax_t imaxabs(intmax_t);
to avoid possible clashes with user code in case someone uses
before including Newlib's inttypes.h (or uses some other conflicting
definition)
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
As discussed in GCC bug 97088
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088), parameters in
prototypes of library functions should use reserved names, or no name
at all.
This patch removes the 'x' parameter name from
extern int __isinff (float);
extern int __isinfd (double);
extern int __isnanf (float);
extern int __isnand (double);
extern int __fpclassifyf (float);
extern int __fpclassifyd (double);
extern int __signbitf (float);
extern int __signbitd (double);
to avoid possible clashes with user code in case someone uses
before including Newlib's math.h (or uses some other conflicting
definition)
The current gamma, gamma_r, gammaf and gammaf_r functions return
|gamma(x)| instead of ln(|gamma(x)|) due to a change made back in 2002
to the __ieee754_gamma_r implementation. This patch fixes that, making
all of these functions map too their lgamma equivalents.
To fix the underlying bug, the __ieee754_gamma functions have been
changed to return gamma(x), removing the _r variants as those are no
longer necessary. Their names have been changed to __ieee754_tgamma to
avoid potential confusion from users.
Now that the __ieee754_tgamma functions return the correctly signed
value, the tgamma functions have been modified to use them.
libm.a now exposes the following gamma functions:
ln(|gamma(x)|):
__ieee754_lgamma_r
__ieee754_lgammaf_r
lgamma
lgamma_r
gamma
gamma_r
lgammaf
lgammaf_r
gammaf
gammaf_r
lgammal (on machines where long double is double)
gamma(x):
__ieee754_tgamma
__ieee754_tgammaf
tgamma
tgammaf
tgammal (on machines where long double is double)
Additional aliases for any of the above functions can be added if
necessary; in particular, I'm not sure if we need to include
__ieee754_gamma*_r functions (which would return ln(|(gamma(x)|).
Signed-off-by: Keith Packard <keithp@keithp.com>
----
v2:
Switch commit message to ASCII
The MSP430 target supports both 16-bit and 20-bit size_t and intptr_t.
Some implicit casts in Newlib expect these types to be
"long", (a 32-bit type on MSP430) which causes warnings during
compilation such as:
"cast from pointer to integer of different size"
