Re: Reducing the size of C++ executables - eliminating malloc

[Mark Mitchell <mark at codesourcery dot com>]

Michael Eager wrote:
> GCC 4.1.1 for PowerPC generates a 162K executable for a
> minimal program  "int main() { return 0; }".  GCC 3.4.1
> generated a 7.2K executable.  Mark Mitchell mentioned the
> same problem for ARM and proposed a patch to remove the
> reference to malloc in atexit
> (http://sourceware.org/ml/newlib/2006/msg00181.html).
> 
> There are references to malloc in eh_alloc.c and
> unwind-dw2-fde.c.  It looks like these are being
> included even when there are no exception handlers.
> 
> Any suggestions on how to eliminate the references
> to these routines?

These aren't full implementation sketches, but, yes, we can do better.
Here are some ideas:

1. For the DWARF unwind stuff, have the linker work out how much space
is required and pre-allocate it.  The space required is a statically
knowable property of the executable, modulo dynamic linking, and on the
cases where we care most (bare-metal) we don't have to worry about
dynamic linking.  (If you can afford a dynamic linker, you can probably
afford malloc, and it's in a shared library.)

2. For the EH stuff, the maximum size of an exception is also statically
knowable, again assuming no dynamic linking.  The maximum exception
nesting depth (i.e., the number of simultaneously active exceptions) is
not, though.  So, here, what I think you want is a small, statically
allocated stack, at least as big as the biggest exception, out of which
you allocate exception objects.  Happily, we already have this, in the
form of "emergency_buffer" -- although it uses a compile-time estimate
of the biggest object, rather than having the linker fill it in, as
would be ideal.  But, in the no-malloc case, just fall back to the
emergency mode.

You could also declare malloc "weak" in that file, and just not call it
if the value is zero.  That way, if malloc is around, you can use it --
but if it's not, you use the emergency buffer.  Put the emergency_buffer
in a separate file (rather than in eh_alloc.cc), so that users can
provide their own implementation to control the size, overriding the one
in the library.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713