At 01:35 PM 9/22/2004, you wrote:Hi all,
I build a static library of input/output functions with PRC-tools.
I wish that programs which link to this library pick up only the functions they need, so the prc file remains as small as possible.
The tests I've done show that the whole library is linked. I looked into PRC-tools documentation and didn't find an optimization option which remove unused code. Is there a way to do this ?
You'll have to write your own build script to do this. prc-tools doesn't support the -ffunction-sections switch that is needed to have an object file separate all the code into different sections. However, in building the Palm OS Glue libraries for prc-tools, we modified the source files so by using #defines, you could build a source file for a single function, and then built the source files lots of times to produce individual object files per public function.
Here's a little more background that I got from John Marshall once. I found it interesting, so I thought I'd pass it on:
Why does the [COFF] format preclude function-level stripping? Or should I just go off and read the COFF documentation?
Consider
int foo () { static int i; return i++; }
int bar () { static int j; return j++; }
Normally in COFF or ELF these get compiled into just two monolithic sections: .text and .bss. After assembly, i and j are still in the symbol table, but the references in the code to them are represented as relocations to an offset within .bss, not as relocations to the named symbols. (There's a reason for canonicalising the relocs like this, but I've forgotten what it is.)
It'd (just) be possible to strip unused functions from .text, but it'd be no fun because you'd have to fix up all the offsets to other places in .text. It'd be an absolute bitch to strip the corresponding unused data from .bss!
If you compile with -ffunction-sections -fdata-sections, the above gets compiled into .text.foo, .text.bar, .bss.i.0, .bss.j.1 (and the linker has to work much harder). Dropping entire sections is a much more practical operation than hacking around inside them.
-- Keith Rollin -- Palm Developer Tools engineer
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
