> You could have several seperate C files for several functions. Hash.c,
> decrypt.c, encrypt.c. No problem at all to maintain.
Because changing the names of the C files makes a difference to the object code?
Maybe you should change your variable names to A, B, C to make it harder to
disassemble ;-) and re-use them through the code (or mabye just use -O 3, and
let the compiler do it for you).
Finding the size of the objects, still the best method, and most reliable is
using a custom linker script. The compiler can use things like multiply from
libc (or libgcc) which could end up in flash, you need to make sure that these
not linked to flash routines. The RAM code should also init its scratch RAM and
stack pointer or else you could overflow the stack into your code.
Making a C 'program' with a main etc and using a custom linker script, and
using a loader to copy it into RAM is reliable. You can set separate load and
virtual address in the linker script, and pass these addresses to the load/run
routines at link time with the linker script. This gets around the problem of
re-ordering functions or the optimizer changing the size of functions.
It would be possible to mod gcc to make a symbol set to the size of a
functions, but the linker script is far more reliable, and less compiler
dependent.
Peter Jansen
__________________________________________________________________________________
Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
Enter now: http://au.docs.yahoo.com/homepageset/
