Go to file
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
.github/workflows Cygwin: CI configuration update 2021-04-30 14:22:07 +01:00
config Sync with upstream gcc. 2016-06-23 15:54:55 -04:00
etc Remove spurious empty line in changelog entry. 2016-03-22 10:29:22 +01:00
include Sync with upstream gcc. 2016-06-23 15:54:55 -04:00
libgloss RISC-V: Using SYS_clock_gettime64 for rv32 libgloss. 2021-04-13 12:54:49 +02:00
newlib Nano-malloc: Fix for unwanted external heap fragmentation 2021-05-03 13:00:33 +02:00
texinfo * texinfo/texinfo.tex: Update to version 2009-03-28.05. 2009-04-21 12:36:46 +00:00
winsup Cygwin: Ensure toollibdir exists before installing a link there 2021-04-30 21:06:33 +02:00
.appveyor.yml Cygwin: CI configuration update 2021-04-30 14:22:07 +01:00
.gitattributes Add .gitattributes 2015-03-09 20:53:11 +01:00
.gitignore Cygwin: drop all generated autotools files 2021-04-29 11:16:38 +02:00
COPYING 2005-07-14 Kelley Cook <kcook@gcc.gnu.org> 2005-07-14 01:24:56 +00:00
COPYING.LIB Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00
COPYING.LIBGLOSS RISC-V: Add semihosting support 2020-12-16 16:40:34 -05:00
COPYING.NEWLIB RTEMS: Add <poll.h> and <sys/poll.h> 2021-01-05 13:41:34 -05:00
COPYING3 * COPYING3: New file. Contains version 3 of the GNU General Public License. 2007-07-17 13:50:23 +00:00
COPYING3.LIB * COPYING3: New file. Contains version 3 of the GNU General Public License. 2007-07-17 13:50:23 +00:00
ChangeLog Sync with upstream gcc. 2016-06-23 15:54:55 -04:00
MAINTAINERS MAINTAINERS: clarify policy with config/ (and other top level files) 2012-05-12 03:10:17 +00:00
Makefile.def Sync with upstream gcc. 2016-06-23 15:54:55 -04:00
Makefile.in Introduce @unless/@endunless and postbootstrap Makefile targets 2018-06-30 00:12:40 -03:00
Makefile.tpl Introduce @unless/@endunless and postbootstrap Makefile targets 2018-06-30 00:12:40 -03:00
README 19990502 sourceware import 1999-05-03 07:29:06 +00:00
README-maintainer-mode Cleanups after the update to Autoconf 2.64, Automake 1.11. 2009-08-22 17:08:06 +00:00
compile Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00
config-ml.in Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00
config.guess Bump config.guess and config.sub 2021-02-24 11:03:28 +01:00
config.rpath Remove freebsd1 from libtool.m4 macros and config.rpath. 2011-02-13 21:00:08 +00:00
config.sub Bump config.guess and config.sub 2021-02-24 11:03:28 +01:00
configure Introduce @unless/@endunless and postbootstrap Makefile targets 2018-06-30 00:12:40 -03:00
configure.ac Introduce @unless/@endunless and postbootstrap Makefile targets 2018-06-30 00:12:40 -03:00
depcomp Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00
djunpack.bat * djunpack.bat: Use ".." quoting in Sed command, for the sake of 2009-03-27 13:37:09 +00:00
install-sh Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00
libtool.m4 Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00
ltgcc.m4 * libtool.m4: Update to libtool 2.2.6. 2008-09-29 15:28:14 +00:00
ltmain.sh PR target/59788 2014-02-05 13:17:47 +00:00
ltoptions.m4 Sync Libtool from GCC. 2010-01-09 21:11:32 +00:00
ltsugar.m4 * libtool.m4: Update to libtool 2.2.6. 2008-09-29 15:28:14 +00:00
ltversion.m4 Sync Libtool from GCC. 2010-01-09 21:11:32 +00:00
lt~obsolete.m4 Sync Libtool from GCC. 2010-01-09 21:11:32 +00:00
makefile.vms 19990502 sourceware import 1999-05-03 07:29:06 +00:00
missing Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00
mkdep Use remove-advertising-clause script to edit BSD licenses 2020-01-29 19:03:31 +01:00
mkinstalldirs Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00
move-if-change Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00
setup.com 2009-09-01 Tristan Gingold <gingold@adacore.com> 2009-09-01 13:38:26 +00:00
src-release * src-release (do-proto-toplevel): Support subdir-path-prefixed 2013-10-15 20:45:52 +00:00
symlink-tree 2005-07-14 Kelley Cook <kcook@gcc.gnu.org> 2005-07-14 01:24:56 +00:00
ylwrap Sync toplevel with upstream GCC. 2016-03-22 10:25:20 +01:00

README

		   README for GNU development tools

This directory contains various GNU compilers, assemblers, linkers, 
debuggers, etc., plus their support routines, definitions, and documentation.

If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README;  if with a libg++ release,
see libg++/README, etc.  That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.

It is now possible to automatically configure and build a variety of
tools with one command.  To build all of the tools contained herein,
run the ``configure'' script here, e.g.:

	./configure 
	make

To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
	make install

(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''.  You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)

If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make.  For example (assuming sh/bash/ksh):

	CC=gcc ./configure
	make

A similar example using csh:

	setenv CC gcc
	./configure
	make

Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc.  See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.

REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
on where and how to report problems.