BL51: ORDER OF MODULES IN LINKING USING IN-LINE ASSEMBLY
Information in this article applies to:
When changing the order in which object modules are linked, sometimes the generated application works and sometimes it fails.
There are a number of things that could cause this problem:
If you use in-line assembly, it is very important to compile the .C files before any .SRC files. The .C files with in-line assembly generate the .SRC files. The .SRC files depend on the .C files.
If you compile the .SRC file first (the old one), then compile the .C file (with changes), the compiler generates a new .SRC file (but the old copy is the one that is compiled and linked).
To resolve this kind of problem, make sure the order of .C and .SRC files is correct.
A source file may include a function that uses memory it doesn't own. Indexing off the end of an array is just one example of this kind of problem. For example:
unsigned char array; . . . array = 0xFF; // Illegal because array has only // 10 elements array-array
Changing the order in which files are linked locates an important data item after array. And, this item gets overwritten.
To resolve this kind of problem, you must analyze which files were modev to cause the problem. Then, look at those files and the ones before and after them in the link order. It may be worthwhile to use a utility like PC-Lint to verify your C code.
STARTUP Code Issues
The STARTUP code (and initialization code for real-time kernels) must be included at the end of the linker module list.
To resolve this kind of problem, make sure the STARTUP code is linked last.
Last Reviewed: Monday, May 31, 2004
of your data.