Commit Graph

3291 Commits

Author SHA1 Message Date
Corinna Vinschen 50405603ea posix_spawn: fix get/set uid/gid calls for 32 bit Cygwin
32 bit Cygwin still exports function calls to support old applications.
E. g., when switching from 16 to 32 bit uid/gid values, new function
like getuid32 have been added and the old getuid function still only
provides 16 bit values.  Newly built applications using getuid are
actually calling getuid32.

However, this link magic isn't performed inside Cygwin itself, so if
newlib functions call getuid, they actually call the old getuid, not
the new getuid32.  This leads to truncated uid/gid values.

https://cygwin.com/pipermail/cygwin/2022-January/250453.html reports
how this leads to problems in posix_spawn.

Fix this temporarily. i686 support will go away soon in Cygwin and the
fix can be dropped.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2022-01-12 11:57:53 +01:00
Takashi Yano 42cbd7b0a1 frexpl: Support smaller long double of LDBL_MANT_DIG == 53.
- Currently, frexpl() supports only the following cases.
    1) LDBL_MANT_DIG == 64 or 113
    2) 'long double' is equivalent to 'double'
  This patch add support for LDBL_MANT_DIG == 53.
2021-12-03 19:14:53 +09:00
Takashi Yano 362598b118 stdio: Fix issue of printing "%La" format with large exp part.
- Currently, printf("%La\n", 1e1000L) crashes with segv due to lack
  of frexpl() function. With this patch, frexpl() function has been
  implemented in libm to solve this issue.

Addresses: https://sourceware.org/pipermail/newlib/2021/018718.html
2021-11-29 23:14:12 +09:00
Takashi Yano 11558121f5 ldtoa: Fix insufficient valid output digits for "%f" format.
- If the number has large integer part and small fraction part is
  specified in output format, e.g. printf("%.3f", sqrt(2)*1e60);,
  valid output digits were insufficient. This patch fixes the issue.
2021-11-26 06:47:27 +09:00
Corinna Vinschen dda1874380 ldtoa: don't restrict outbuf size to ndigits
https://cygwin.com/pipermail/cygwin/2021-November/249930.html
reported a regression introduce by using a dynamically sized local
char array in favor of a statically sized array.

Fix this by reverting to a statically sized array, using a small
buffer on the stack for a reasonable number of requested digits, a
big mallocated buffer otherwise.  This should work for small targets
as well, given that malloc is used in printf anyway right now.

This is *still* hopefully just a temporary measure, unless somebody
actually provides a new ldtoa.

Fixes: 4d90e53359 ("ldtoa: fix dropping too many digits from output")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-11-22 13:58:36 +01:00
Corinna Vinschen 97dac2bbcb ldtoa: fix dropping too many digits from output
ldtoa cuts the number of digits it returns based on a computation of
number of supported bits (144) divide by log10(2).  Not only is the
integer approximation of log10(2) ~= 8/27 missing a digit here, it
also fails to take really small double and long double values into
account.

Allow for the full potential precision of long double values.  At the
same time, change the local string array allocation to request only as
much bytes as necessary to support the caller-requested number of
digits, to keep the stack size low on small targets.

In the long run a better fix would be to switch to gdtoa, as the BSD
variants, as well as Mingw64 do.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-11-04 13:15:39 +01:00
Christian Biesinger via Newlib 26894de91d Unconditionally declare strsignal
Currently, newlib does not declare strsignal if DEFS_H is defined,
ostensibly to work around a gdb bug. However, gdb itself compiles
even with this ifndef removed, and this makes sim (another part of
gdb) fail to compile.

Since it is not clear exactly what issue this was working around,
this patch just replaces that ifdef with the correct check,
i.e. __POSIX_VISIBLE >= 200809.
2021-10-27 20:02:06 +02:00
Keith Packard c51f05c597 string: Fix buffer overrun in picolibc/newlib/libc/string/strrchr.c (#184)
Reported by prodisDown:

	In picolibc/newlib/libc/string/strrchr.c

	if (i) { while ((s=strchr(s, i))) { last = s; s++; } } else { last = strchr(s, i); }

	Value (for example 0xFFFFFF00) in if (i) can pass test and
	then be typecasted to char inside strchr(). Then s++ and then
	buffer overrun.

	It can be fixed by preventive typecast i = (int) (char) i; or
	typecasting inside expression if ((char) i).

Fixed by casting to char.

Signed-off-by: Keith Packard <keithp@keithp.com>
2021-10-13 16:39:49 -04:00
Sebastian Huber eb03ac17f1 sys/tree.h: Red child with black sibling rotations
Add specialized rotations RB_RED_ROTATE_LEFT() and RB_RED_ROTATE_RIGHT() which
may be used if we rotate a red child which has a black sibling.  Such a red
node must have at least two child nodes so that the following red-black tree
invariant is fulfilled:

  Every path from a given node to any of its descendant NULL nodes goes through
  the same number of black nodes.

      PARENT
     /      \
  BLACK     RED
           /   \
        BLACK BLACK
2021-10-07 17:58:36 +02:00
Sebastian Huber 5f7f27c817 sys/tree.h: Add parent rotations
Add specialized rotations RB_PARENT_ROTATE_LEFT() and RB_PARENT_ROTATE_RIGHT()
which may be used if the parent node exists and the direction of the child is
known.  The specialized rotations are derived from RB_ROTATE_LEFT() and
RB_ROTATE_RIGHT() where the RB_SWAP_CHILD() was replaced by a simple
assignment.
2021-10-05 17:21:18 +02:00
Sebastian Huber ee30f991c3 sys/tree.h: Simplify chain of conditions
In RB_GENERATE_REMOVE_COLOR() simplify a chain of conditions of the following
pattern

if (x) {
  ...
} else if (!x) {
  ...
}

to

if (x) {
  ...
} else {
  ...
}
2021-10-05 16:09:50 +02:00
Sebastian Huber 098cf0f98d sys/tree.h: Simplify loop condition
We have

  #define RB_ISRED(elm, field) \
    ((elm) != NULL && RB_COLOR(elm, field) == RB_RED)

So, the RB_ISRED() contains an implicit check for NULL.  In
RB_GENERATE_REMOVE_COLOR() the "elm" pointer cannot be NULL in the while
condition.  Use RB_COLOR(elm) == RB_BLACK instead.
2021-10-05 16:09:11 +02:00
Mike Frysinger 6e64fccb5f newlib: sig2str: use __restrict
This matches the header prototype style and most of newlib, and fixes
building with older versions of gcc which only accept the __ form.
2021-09-15 10:08:20 -04:00
Corinna Vinschen 8c8d3b7a94 Regenerate Makefile.in after configure.in -> configure.ac change
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-09-13 17:25:46 +02:00
Mike Frysinger e8e0eb7398 Add myself to sim & general write-after-approval maintainers
There are a few files that are tied to the GNU simulator, so add myself
to match the general sim project.

Also add myself to the general write-after-approval since I've been doing
that for a long time now anyways :).
2021-09-13 10:14:37 -04:00
Mike Frysinger 920617998e libgloss/newlib: rename configure.in to configure.ac
The .in name has been deprecated for a long time in favor of .ac.
2021-09-13 10:14:37 -04:00
Torbjorn SVENSSON via Newlib 522cdab541 nano-malloc: Fix redefined compilation warning
When newlib is configured with --enable-newlib-reent-check-verify,
the assert macro is already defined in the nano-mallocr.c compile unit.

Contributed by STMicroelectronics

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
2021-09-06 20:29:39 +02:00
Corinna Vinschen 76c2c7a891 ldexp/ldexpf: avoid assembler warning
libm/machine/i386/f_ldexp.S:30: Warning: no instruction mnemonic suffix given and no register operands; using default for `fild'
libm/machine/i386/f_ldexpf.S:30: Warning: no instruction mnemonic suffix given and no register operands; using default for `fild'

fix this by adding the l mnemonic suffix

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-09-03 12:52:47 +02:00
Corinna Vinschen c2fe205b50 strstr: avoid warnings
unused function warning for two_way_short_needle,
different char type warnings for standard string functions

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-09-03 12:51:30 +02:00
Corinna Vinschen 6a35ae33f5 nftw: fix thread cancellation support
_STDIO_WITH_THREAD_CANCELLATION_SUPPORT was never defined.
Include ../stdio/local.h to get the right definition per target.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-09-03 12:26:17 +02:00
Joel Sherrill dcb515a953 libc/include/sys/signal.h: Change __STDINT_EXP() to __SIZEOF_INT__
__STDINT_EXP() is provided by newlib but not by stdint-gcc.h. stdint-gcc.h
is used when the GCC argument -ffreestanding is used and this results in this
file not compiling.
2021-08-27 11:41:56 -05:00
Roger Sayle 6bb96d13a2 nvptx: Emulate clock and other machine stubs.
This patch to the libc/machine/nvptx port of newlib implements an
approximation of "clock" and provides some additional stub routines.
These changes not only reduce the number of (link) failures in the GCC
testsuite when targeting nvptx-none, but also allow the NIST scimark4
benchmark to compile and run without modification.

newlib already contains support for backends to provide their own
clock implementations via -DCLOCK_PROVIDED.  That functionality is
used here to return an approximate elapsed time based on the NVidia
GPU's clock64 cycle counter.  Although not great, this is better than
the current behaviour of link error from the unresolved symbol
_times_r.

The other part of the patch is to add a small number of stub functions
to nvptx's misc.c.  Adding isatty, for example, resolves linking
problems in libc from the dependency in __smakebuf_r, and the sync
stub, for example, fixes the failure with GCC's
testsuite/gfortran.dg/ISO_Fortran_binding_14.f90 [which simply tests
that gfortran can call a/any C function].

newlib/
        configure.host: Add -DCLOCK_PROVIDED to newlib_cflags on nvptx*.

newlib/libc/machine/nvptx
        Makefile.am: Add clock.c to lib_a_SOURCES.
        clock.c: New source file to implement/approximate clock().
        misc.c: Add stubs for fstat, isatty, open, sync and unlink.
2021-08-25 10:20:27 +02:00
Corinna Vinschen bc0e8a9961 stdlib: conditionalize locale usage
_strtod_l as well as the gethex function both fetch the decimal point
from the current LC_NUMERIC locale info.  This pulls in _C_numeric_locale
unconditionally even on targets not supporting locales at all.

Another problem is that strtod.c and gdtoa-gethex.c are ELIX 1, while
locale information in general isn't.  This leads to potential build
breakage on bare metal targets.

Fix this by setting the decimal point to "." on all targets not
defining __HAVE_LOCALE_INFO__.

While at it, const'ify the entire local decimal point info in the
affected functions.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-08-23 10:02:00 +02:00
Keith Packard cf86601d98 svfwscanf: Simplify _sungetwc_r to eliminate apparent buffer overflow
svfwscanf replaces getwc and ungetwc_r. The comments in the code talk
about avoiding file operations, but they also need to bypass the
mbtowc calls as svfwscanf operates on wchar_t, not multibyte data,
which is a more important reason here; they would not work correctly
otherwise.

The ungetwc replacement has code which uses the 3 byte FILE _ubuf
field, but if wchar_t is 32-bits, this field is not large enough to
hold even one wchar_t value. Building in this mode generates warnings
about array overflow:

	In file included from ../../newlib/libc/stdio/svfiwscanf.c:35:
	../../newlib/libc/stdio/vfwscanf.c: In function '_sungetwc_r.isra':
	../../newlib/libc/stdio/vfwscanf.c:316:12: warning: array subscript 4294967295 is above array bounds of 'unsigned char[3]' [-Warray-bounds]
	  316 |   fp->_p = &fp->_ubuf[sizeof (fp->_ubuf) - sizeof (wchar_t)];
	      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	In file included from ../../newlib/libc/stdio/stdio.h:46,
			 from ../../newlib/libc/stdio/vfwscanf.c:82,
			 from ../../newlib/libc/stdio/svfiwscanf.c:35:
	../../newlib/libc/include/sys/reent.h:216:17: note: while referencing '_ubuf'
	  216 |   unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */
	      |                 ^~~~~

However, the vfwscanf code *never* ungets data before the start of the
scanning operation, and *always* ungets data which matches the input
at that point, so the code always hits the block which backs up over
the input data and never hits the block which uses the _ubuf field.

In addition, the svfwscanf code will always start with the unget
buffer empty, so the ungetwc replacement never needs to support an
unget buffer at all.

Simplify the code by removing support for everything other than
backing up over the input data, leaving the check to make sure it
doesn't get underflowed in case the vfscanf code has a bug in it.

Signed-off-by: Keith Packard <keithp@keithp.com>
2021-08-18 10:37:24 +02:00
Matt Joyce 4f81149937 libc: Added prototypes for new POSIX APIs
Added function prototypes to newlib/libc/include/pthread.h
for the following Issue 8 Standard APIs:
pthread_cond_clockwait()
pthread_mutex_clocklock()
pthread_rwlock_clockrdlock()
pthread_rwlock_clockwrlock()
2021-08-09 10:29:55 +02:00
Christoph Muellner 15c53a34bc libc: Fix compilation for new sig2str/str2sig implementation
A recent patch introduced new code for sig2str/str2sig.
This code does not properly exclude code that requires
SIGRTMIN/SIGRTMAX to be defined and triggers the following
compile error:

  newlib/libc/signal/sig2str.c:199:8: error: 'SIGRTMIN' undeclared
  newlib/libc/signal/sig2str.c:200:29: error: 'SIGRTMAX' undeclared

Let's add the missing guards.

Fixes: 2b50ec0cd2 ("libc: Fix compilation for new sig2str/str2sig implementation")

Signed-off-by: Christoph Muellner <cmuellner@gcc.gnu.org>
2021-08-02 16:42:03 +02:00
Matt Joyce 2b50ec0cd2 libc: Added implementation for sig2str/str2sig.
Added implementations for sig2str() and str2sig() in libc/signal
in order to improve POSIX compliance. Added fucntion prototypes
in libc/include/sys/signal.h.
2021-08-02 11:28:15 +02:00
Maxim Blinov 0542583129 Remove unneccesary parenthesis around declarator
riscv64-unknown-elf-g++-11.1.0 regression suite reports the following
failures for

$ make check-gcc-c++ RUNTESTFLAGS='dg.exp=Wstringop-overflow-6.C'

```
FAIL: g++.dg/warn/Wstringop-overflow-6.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-6.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-6.C  -std=gnu++2a (test for excess errors)
UNSUPPORTED: g++.dg/warn/Wstringop-overflow-6.C  -std=gnu++98
```

The "excess errors" being

```
output is In file included from /home/maxim/prj/riscv-upstream/install/riscv64-unknown-elf/include/wchar.h:6,
                 from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/cwchar:44,
                 from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/bits/postypes.h:40,
                 from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/iosfwd:40,
                 from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/ios:38,
                 from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/ostream:38,
                 from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/iostream:39,
                 from /home/maxim/prj/riscv-upstream/gcc-11.1.0/gcc/testsuite/g++.dg/warn/Wstringop-overflow-6.C:6:
/home/maxim/prj/riscv-upstream/install/riscv64-unknown-elf/include/sys/reent.h:685:11: warning: unnecessary parentheses in declaration of '_sig_func' [-Wparentheses]
```
2021-07-28 11:12:42 +02:00
Alex White 44a3966577 libc/include/sys/config.h: Undef _REENT_SMALL for RTEMS on MicroBlaze
RTEMS does not expect _REENT_SMALL.
2021-07-22 09:35:17 +02:00
Kito Cheng ca7b4bd236 libm: Fixing overflow handling issue for scalbnf and scalbn
cc Aldy Hernandez <aldyh@redhat.com> and Andrew MacLeod <amacleod@redhat.com>,
they are author of new VRP analysis for GCC, just to make sure I didn't
mis-understanding or mis-interpreting anything on GCC site.

GCC 11 have better value range analysis, that give GCC more confidence
to perform more aggressive optimization, but it cause scalbn/scalbnf get
wrong result.

Using scalbn to demostrate what happened on GCC 11, see comments with VRP
prefix:

```c
double scalbn (double x, int n)
{
	/* VRP RESULT: n = [-INF, +INF] */
        __int32_t  k,hx,lx;
        ...
        k = (hx&0x7ff00000)>>20;
	/* VRP RESULT: k = [0, 2047] */
        if (k==0) {
	    /* VRP RESULT: k = 0 */
	    ...
	    k = ((hx&0x7ff00000)>>20) - 54;
            if (n< -50000) return tiny*x;       /*underflow*/
	    /* VRP RESULT: k = -54 */
	}
	/* VRP RESULT: k = [-54, 2047] */
        if (k==0x7ff) return x+x;               /* NaN or Inf */
	/* VRP RESULT: k = [-54, 2046] */
        k = k+n;
        if (k > 0x7fe) return huge*copysign(huge,x); /* overflow  */
	/* VRP RESULT: k = [-INF, 2046] */
	/* VRP RESULT: n = [-INF, 2100],
	   because k + n <= 0x7fe is false, so:
	   1. -INF < [-54, 2046] + n <= 0x7fe(2046) < INF
	   2. -INF < [-54, 2046] + n <= 2046 < INF
	   3. -INF < n <= 2046 - [-54, 2046] < INF
	   4. -INF < n <= [0, 2100] < INF
	   5. n = [-INF, 2100] */
        if (k > 0)                              /* normal result */
            {SET_HIGH_WORD(x,(hx&0x800fffff)|(k<<20)); return x;}
        if (k <= -54) {
	    /* VRP OPT: Evaluate n > 50000 as true...*/
            if (n > 50000)      /* in case integer overflow in n+k */
                return huge*copysign(huge,x);   /*overflow*/
            else return tiny*copysign(tiny,x);  /*underflow*/
	}
        k += 54;                                /* subnormal result */
        SET_HIGH_WORD(x,(hx&0x800fffff)|(k<<20));
        return x*twom54;
}
```

However give the input n = INT32_MAX, k = k+n will overflow, and then we
expect got `huge*copysign(huge,x)`, but new VRP optimization think
`n > 50000` is never be true, so optimize that into `tiny*copysign(tiny,x)`.

so the solution here is to moving the overflow handle logic before `k = k + n`.
2021-07-21 09:56:04 +02:00
Kito Cheng 91f99d323b Minimal support for ISO/IEC TS 18661-3.
- GCC will set __FLT_EVAL_METHOD__ to 16 if __fp16 supported, e.g.
   cortex-a55/aarch64.
   - $ aarch64-unknown-elf-gcc -v 2>&1 |grep version
     gcc version 9.2.0 (GCC)
   - $ aarch64-unknown-elf-gcc  -E -dM -mcpu=cortex-a55 - < /dev/null  |grep FLT_EVAL_METHOD
     #define __FLT_EVAL_METHOD__ 16
     #define __FLT_EVAL_METHOD_TS_18661_3__ 16
     #define __FLT_EVAL_METHOD_C99__ 16
 - The behavior of __FLT_EVAL_METHOD__ == 16 is same as
   __FLT_EVAL_METHOD__ == 0 except for float16_t, but newlib didn't
   support float16_t.

ISO/IEC TS 18661-3:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2405.pdf

V2 Changes:
- List Howland, Craig D as co-author since he provide the draft of comment
  in math.h.

Co-authored-by: "Howland, Craig D" <howland@LGSInnovations.com>
2021-07-12 21:07:43 +02:00
Keith Packard fb01286fab stdlib: Make strtod/strtof set ERANGE consistently for underflow.
The C standard says that errno may acquire the value ERANGE if the
result from strtod underflows. According to IEEE 754, underflow occurs
whenever the value cannot be represented in normalized form.

Newlib is inconsistent in this, setting errno to ERANGE only if the
value underflows to zero, but not for denorm values, and never for hex
format floats.

This patch attempts to consistently set errno to ERANGE for all
'underflow' conditions, which is to say all values which are not
exactly zero and which cannot be represented in normalized form.

This matches glibc behavior, as well as the Linux, Mac OS X, OpenBSD,
FreeBSD and SunOS strtod man pages.

Signed-off-by: Keith Packard <keithp@keithp.com>
2021-07-07 13:22:02 -04:00
Thomas Wolff 204ee3cf6a fix and amend scripts and makefile rules to generate Unicode data 2021-07-06 15:35:37 +02:00
Thomas Wolff 11fdae24b7 update to Unicode 13.0 2021-07-06 15:35:37 +02:00
Jonathan Wakely a39ae40b86 inttypes.h: Use reserved names for function parameters 2021-06-25 16:48:31 -04:00
Keith Packard 92068f4cc5 stdio: Parse 0x0p+00 correctly in scanf
The scanf code was skipping the '0' after the 'x' causing the
resulting buffer to contain an invalid number when passed to strtod.

Signed-off-by: Keith Packard <keithp@keithp.com>
2021-06-18 17:15:37 -04:00
Joel Sherrill 90a72f27d5 newlib/doc/makedoc.c: if realloc() fails, exit with an error message. 2021-06-17 16:48:47 -05:00
Joel Sherrill 609f5a51c6 newlib/doc/makedoc.c: Fix memory leak identified by Coverity. 2021-06-17 16:27:49 -05:00
Joel Sherrill 59584ff16b libc/sys/rtems/crt0.c: Fix two warnings.
__assert_func() is marked as noreturn and stub should not.
	__tls_get_addr() needed to return a value..
2021-06-17 12:58:36 -05:00
Dimitar Dimitrov b585151016 pru: Enable -ffunction-sections and -fdata-sections
Recent binutils support --gc-sections for pru, so let's make use of
them.

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
2021-06-09 14:07:14 -04:00
Jeff Johnston a9165ea07c Fix rounding issues with sqrt/sqrtf
- compiler is sometimes optimizing out the rounding check in
  e_sqrt.c and ef_sqrt.c which uses two constants to create
  an inexact operation
- there is a similar constant operation in s_tanh.c/sf_tanh.c
- make the one and tiny constants volatile to stop this
2021-06-04 14:42:58 -04:00
Richard Earnshaw 2a3a03972b aarch64: support binary mode for opening files
Newlib for aarch64 uses libgloss for the backend.  One common libgloss
implementation is the 'rdimon' implementation, which uses the Arm
Semihosting protocol.  In order to support a remote host that runs on
Windows we need to know whether a file is to be opened in binary or
text mode.  That means that we need to preserve this information via
O_BINARY until we know what the libgloss binding will be.

This patch simply copies the arm implementation from sys/arm/sys and
puts it in machine/aarch64/sys, because we don't have a 'sys' subtree
on aarch64.
2021-05-26 15:17:11 +01:00
Joel Sherrill 0c0f3df224 sys/stat.h: Enable UTIME_NOW and UTIME_OMIT for RTEMS 2021-05-20 10:04:07 +02:00
Ola Olsson 84d068971d Nano-malloc: Fix for unwanted external heap fragmentation
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.
2021-05-03 13:00:33 +02:00
Mike Frysinger ae6e6c3526 bfin: add myself as maintainer 2021-04-26 11:38:35 +02:00
Ties Stuij 282445a10e fix some Arm FP routines not checking if floating point is enabled
A lot of the Arm FP routines check for the availability of floating point by way
of `(__ARM_FP & 0x4)`. However some do not. This patch remedies this.
2021-04-21 16:18:09 +01:00
Corinna Vinschen 9c6c2fb0f6 scanf: allow hex float input per POSIX
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-04-19 22:00:10 +02:00
David Macek 7078248485 fenv: fix up stub file comment, drop symlinks from description
also slightly fixed up formatting
2021-04-13 12:55:34 +02:00
Corinna Vinschen cc19109af9 Cygwin: don't export _feinitialise from newlib
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>
2021-04-13 12:55:34 +02:00
Corinna Vinschen 3b22d72255 fenv: drop Cygwin-specific implementation in favor of newlib code
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>
2021-04-13 12:55:34 +02:00