This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I just wrote some test scaffolding that will only be called from a DSS script. I compiled and linked the target software, including my test scaffolding source file. When I loaded this file, my test scaffolding code was nowhere to be found in the executable image!
Apparently, the combination of the C compiler (MSP430) and the linker is "doing me a favor" by not including in the executable image any object modules that are not actually referenced, directly or indirectly, from main(). Is there a way to force the toolchain to be more conventional and obedient and include any object modules it was passed, instead of trying to optimize my code?
We are working in a regulated environment, and we have rules against "dead code", which means lines of source code that are present in the source files, but that do not get executed. I have noticed from assembly listings output by the toolchain that if a source file contains multiple procedures, each is apparently placed in its own section, and I was told by another developer on my team that the default behavoior of the toolchain is to exclude functions that are not referenced, even if other functions in the same source file are referenced. Is this true? I need to disable that behavior, preferably with a compiler or linker directive, not a #pragma.
We also have code still under development that might include calls to functions that are called nowhere else. We still need to include those functions in the executable image so we can track our memory consumption, as we have limited code space on the target processor. If functions that are present in source files that are part of the project are not being called, I fear that they are not getting pulled into the executable, and therefore our memory usage figures are lower than they should be.
I determined that the symbols naming the missing function were not present by the following (Unix/Linux/Cygwin) command:
cat <executable>.out | strings | grep <symbol>
This allows me to see if the string naminmg the symbol is present anywhere in the executable image.
Starting with v4.0.0 of the MSP430 compiler tools, the defaut ABI is now EABI. This wiki page gives some background information on the different ABIs/object formats supported by TI: COFF format (which was used by default until v4.0.0) and ELF or EABI format.
In EABI (differenty than COFF), by default, all sections are eligible for removal via conditional linking, so any section that is not referenced will be removed. If a section is needed but unreferenced, they must be explicitly retained. Please see this wiki page for ways to achieve this: http://processors.wiki.ti.com/index.php/C6000_EABI_Migration#Conditional_Linking_Feature
Although the page is written for C6000 processors, it equally applies to other devices as well.