On Tue, 22 May 2007, Ross Drummond wrote:
Sorry, this discussion is going completely over my head.
Can somebody supply a plain language description of the problem?
So you have written a program with gcc. And it has grown fat and
overweight, using too much ram, using too much disk space.
Where is the fat? Which arrays / structures have quietly grown
massive? Which functions take up more space than they should?
This is especially a problem in the embedded systems world. We write
programs that get cross compiled on a linux host and squirted into
some chunk of hardware that usually has far too little ram and not
much rom (usually flash memory).
Unfortunately just putting in a bigger flash memory part tends to
increase the unit cost of the device. Very Bad For Profit.
Fortunately the gcc toolchain comes with large toolbox to tackle such
issues..
The simplist is
size /bin/ls
size text data bss dec hex filename
75190 928 1072 77190 12d86 /bin/ls
My favourite is objdump.
objdump --syms ExecutableFile
gets you a list of every symbol (every function, every global or
static variable, every const), it's type, it's section and it's size.
Most programmers don't even think what the linker does. It just
magically glues all your object files together to create a program and
you can run it.
In the embedded world you need to gaze deeply into the gory guts of
linker scripts. Deep magic lies there allowing you to specify exactly
at what address is your RAM? Which part of the flash address range do you
want to use for your program? (You quite likely will store other
stuff, like non-volatile user data in flash as well.)
The compiler naturally assigns chunks of your programs to different
sections. For example uninitialized static data ends up in the .bss
section, which isn't store in flash. But on boot up, the boot system
must initialize that region of ram to zero.
The initialized data variables end up in the .data section and in
flash and in ram. The boot system must copy that data out of flash (or
off disk if that's what you have) and into ram.
You can get the compiler and the linker to assign functions to
specific sections. For example we assign the part of the flash drivers
that write to flash to be loaded into ram at boot time. Why? Because
we can't execute code out of flash when we are busy writing to it!
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [EMAIL PROTECTED]
New Zealand
