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 [EMAIL PROTECTED] (650) 331-3385 x713