ARM Compiler toolchain Using the Linker - ARM Information Center
ARM Compiler toolchain Using the Linker - ARM Information Center
ARM Compiler toolchain Using the Linker - ARM Information Center
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
4.22.1 Example of a weak reference<br />
Image structure and generation<br />
A library contains a function foo(), that is called in some builds of an application but not in<br />
o<strong>the</strong>rs. If it is used, init_foo() must be called first. Weak references can be used to automate <strong>the</strong><br />
call to init_foo().<br />
The library can define init_foo() and foo() in <strong>the</strong> same ELF section. The application<br />
initialization code must call init_foo() weakly. If <strong>the</strong> application includes foo() for any reason,<br />
it also includes init_foo() and this is called from <strong>the</strong> initialization code. In any builds that do<br />
not include foo(), <strong>the</strong> call to init_foo() is removed by <strong>the</strong> linker.<br />
Typically, <strong>the</strong> code for multiple functions defined within a single source file is placed into a<br />
single ELF section by <strong>the</strong> compiler. However, certain build options might alter this behavior, so<br />
you must use <strong>the</strong>m with caution if your build is relying on <strong>the</strong> grouping of files into ELF<br />
sections:<br />
• The compiler command-line option --split_sections results in each function being<br />
placed in its own section. In this example, compiling <strong>the</strong> library with this option results in<br />
foo() and init_foo() being placed in separate sections. Therefore init_foo() is not<br />
automatically included in <strong>the</strong> build due to a call to foo().<br />
• The linker feedback mechanism, --feedback, records init_foo() as being unused during<br />
<strong>the</strong> link step. This causes <strong>the</strong> compiler to place init_foo() into its own section during<br />
subsequent compilations, so that it can be removed.<br />
• The compiler directive #pragma arm section also instructs <strong>the</strong> compiler to generate a<br />
separate ELF section for some functions.<br />
In this example, <strong>the</strong>re is no need to rebuild <strong>the</strong> initialization code between builds that include<br />
foo() and do not include foo(). There is also no possibility of accidentally building an<br />
application with a version of <strong>the</strong> initialization code that does not call init_foo(), and o<strong>the</strong>r parts<br />
of <strong>the</strong> application that call foo().<br />
An example of foo.c source code that is typically built into a library is:<br />
void init_foo()<br />
{<br />
// Some initialization code<br />
}<br />
void foo()<br />
{<br />
// A function that is included in some builds<br />
// and requires init_foo() to be called first.<br />
}<br />
An example of init.c is:<br />
__weak void init_foo(void);<br />
int main(void)<br />
{<br />
init_foo();<br />
// Rest of code that may make calls foo() directly or indirectly.<br />
}<br />
An example of a weak reference generated by <strong>the</strong> assembler is:<br />
init.s:<br />
IMPORT init_foo WEAK<br />
AREA init, CODE, readonly<br />
<strong>ARM</strong> DUI 0474C Copyright © 2010-2011 <strong>ARM</strong>. All rights reserved. 4-33<br />
ID080411 Non-Confidential