ian,

>1. Crunched executable is statically linked. Does it mean, that when i load
>any crunched "utility" dynamicall linker loads the whole executable 
>imageinto
>memory every time? I.e. it makes an own dedicated copy of code/data 
>sections
>for each exec() and code sections are not shared between different 
>processes?
>If i'm right in my guess, crunchgen let me save my disk space but as the
>price it heavily increases RAM usage and, most likely, time to start
>executables. Specially when file system is located on relatively slow flash
>media.

netbsd loads pages of an excutable into ram when they are needed. so, 
although your multi-call binary is quite large, only those portions 
associated with the command you run will be coppied to ram, and only after 
they are accessed.

now, to make things even more complicated (but for the better!) since the 
multi-call binary is a *single file*, even though you hook into different 
commands of the binary through different hard links. this means that 
read-only pages like text and read-only data will be shared among every 
command from the multi-call binary.

i came up with an equation a while back for the max ram usage of a 
crunchgened binary and it went something like this:

max ram usage = sum(0, n, STACKn + DATAn + BSSn + HEAP_SIZEn) + RODATA + 
TEXT

this is worst case. also note that with a multi-call binary we are saving a 
few pages per process that would go to dynamic linking glue - not a lot, but 
when n gets big it might make a difference.

for a system with swap space such considerations are not essential. however, 
if there is no swap space (i.e. embedded system w/o a hard drive) it might 
be a good idea to evaluate the above equation and adjust ram sizes 
accordingly (assuming your board vendor gives you options or you are 
spinning your own boards).

hope this helps.

best regards,
jared.