06.02.2013 Views

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

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!