Hmm. I'm looking at this problem myself right now...
Several things:
a: Use 'objdump -h' (nios2-elf-objdump) from the nios shell on the .elf file.
This should give you some info on the "static" sizes of things like code, data, bss.
b: for ucos task stacks, note that sizeof(OS_STK) is 4, not 1. So your stack usage may be 4 x higher than you think.
c: If you use LWIP, then 8KB per possible task of stack is preallocated in sys_arch.c. On my system, that took up 504K. A sane person might wish to alter this to use a less brain-dead approach. Also, if a task started with sys_new_task terminates, the stack (and the task priority) are not 'reclaimed' in any way.
d: the newlib 'mallinfo' calls are effectively pointless. Calling 'mallinfo' will give you an idea of how much heap you're using, but you have - AFAIK - NO WAY of telling how much is left, because malloc itself requests memory via sbrk(), which seems to have no concept of the amount of available memory. It just keeps giving malloc more and more...
Has anybody attempted to rebuild newlib yet?
- Roddy
