Re: malloc on tiny systems

[Jeff Johnston <jjohnstn at redhat dot com>]

DJ Delorie wrote:
> The r8c chip has, at most, 1k of RAM.  mallocr.o uses 512 bytes for
> its av_ table (16 bit pointers).  For a trivial program, the only
> reason we include malloc is because __call_exitprocs() calls free().
> We call the regular exit() because that's what main() is supposed to
> do on "exit" although I admit that's meaningless in an embedded
> system, unless you've hacked your runtime to report exit codes across
> the serial link or are using a simulator that can report true exit
> codes, such as for running the gcc testsuite.
>
> Anyway... ideas for avoiding this memory usage?  There doesn't seem to
> be a configure knob for reducing the size of that array.  We could
> make free() a weak symbol, so that it doesn't cause a link of
> mallocr() (although malloc() itself would, and you shouldn't be using
> free() if you haven't malloc()'d anything).
>
> Or should I just cal _exit() instead of exit() from crt0?  It's
> nonstandard, but I can't think of a legitimate (other than my testing)
> reason to call exitprocs, other than proving they work, but the
> simulator has more memory than the chips and can accomodate those.

From the sounds of it, you would want to supply your own simplified 
malloc/free routines that concentrate on low storage overhead.  There is 
a flag: MALLOC_PROVIDED to specify that you have provided your own 
malloc routines if you don't want the stdlib versions compiled.

Regarding your alternative solution of just using _exit(): that solves 
the simplest case, but you still will likely run into code that will 
call exit directly.  There is also what to do with atexit calls that you 
intend to ignore.  I suppose you could override exit and atexit so 
atexit returns failure and exit is equivalent to _exit.

-- Jeff J.