<li> Input source file <tt>a.c</tt> is compiled into LLVM bitcode form.
<li> Input source file <tt>main.c</tt> is compiled into native object code.
</ul>
-<div class="doc_code"><pre>
+<pre class="doc_code">
--- a.h ---
extern int foo1(void);
extern void foo2(void);
$ llvm-gcc --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bitcode file
$ llvm-gcc -c main.c -o main.o # <-- main.o is native object file
$ llvm-gcc a.o main.o -o main # <-- standard link command without any modifications
-</pre></div>
+</pre>
<p>In this example, the linker recognizes that <tt>foo2()</tt> is an
externally visible symbol defined in LLVM bitcode file. The linker completes
its usual symbol resolution
provided by the linker on various platform are not unique. This means,
this new tool needs to support all such features and platforms in one
super tool or a separate tool per platform is required. This increases
- maintance cost for link time optimizer significantly, which is not
+ maintenance cost for link time optimizer significantly, which is not
necessary. This approach also requires staying synchronized with linker
developements on various platforms, which is not the main focus of the link
time optimizer. Finally, this approach increases end user's build time due
user-supplied information, such as a list of exported symbols. LLVM
optimizer collects control flow information, data flow information and knows
much more about program structure from the optimizer's point of view.
- Our goal is to take advantage of tight intergration between the linker and
+ Our goal is to take advantage of tight integration between the linker and
the optimizer by sharing this information during various linking phases.
</p>
</div>
</div>
<div class="doc_text">
- <p>A non-native object file is handled via an <tt>lto_module_t</tt>.
- The following functions allow the linker to check if a file (on disk
- or in a memory buffer) is a file which libLTO can process: <pre>
- lto_module_is_object_file(const char*)
- lto_module_is_object_file_for_target(const char*, const char*)
- lto_module_is_object_file_in_memory(const void*, size_t)
- lto_module_is_object_file_in_memory_for_target(const void*, size_t, const char*)</pre>
- If the object file can be processed by libLTO, the linker creates a
- <tt>lto_module_t</tt> by using one of <pre>
- lto_module_create(const char*)
- lto_module_create_from_memory(const void*, size_t)</pre>
- and when done, the handle is released via<pre>
- lto_module_dispose(lto_module_t)</pre>
- The linker can introspect the non-native object file by getting the number
- of symbols and getting the name and attributes of each symbol via: <pre>
- lto_module_get_num_symbols(lto_module_t)
- lto_module_get_symbol_name(lto_module_t, unsigned int)
- lto_module_get_symbol_attribute(lto_module_t, unsigned int)</pre>
- The attributes of a symbol include the alignment, visibility, and kind.
-</p>
+
+<p>A non-native object file is handled via an <tt>lto_module_t</tt>.
+The following functions allow the linker to check if a file (on disk
+or in a memory buffer) is a file which libLTO can process:</p>
+
+<pre class="doc_code">
+lto_module_is_object_file(const char*)
+lto_module_is_object_file_for_target(const char*, const char*)
+lto_module_is_object_file_in_memory(const void*, size_t)
+lto_module_is_object_file_in_memory_for_target(const void*, size_t, const char*)
+</pre>
+
+<p>If the object file can be processed by libLTO, the linker creates a
+<tt>lto_module_t</tt> by using one of</p>
+
+<pre class="doc_code">
+lto_module_create(const char*)
+lto_module_create_from_memory(const void*, size_t)
+</pre>
+
+<p>and when done, the handle is released via</p>
+
+<pre class="doc_code">
+lto_module_dispose(lto_module_t)
+</pre>
+
+<p>The linker can introspect the non-native object file by getting the number of
+symbols and getting the name and attributes of each symbol via:</p>
+
+<pre class="doc_code">
+lto_module_get_num_symbols(lto_module_t)
+lto_module_get_symbol_name(lto_module_t, unsigned int)
+lto_module_get_symbol_attribute(lto_module_t, unsigned int)
+</pre>
+
+<p>The attributes of a symbol include the alignment, visibility, and kind.</p>
</div>
<!-- ======================================================================= -->
</div>
<div class="doc_text">
- <p>Once the linker has loaded each non-native object files into an
- <tt>lto_module_t</tt>, it can request libLTO to process them all and
- generate a native object file. This is done in a couple of steps.
- First a code generator is created with:<pre>
- lto_codegen_create() </pre>
- then each non-native object file is added to the code generator with:<pre>
- lto_codegen_add_module(lto_code_gen_t, lto_module_t)</pre>
- The linker then has the option of setting some codegen options. Whether
- or not to generate DWARF debug info is set with: <pre>
- lto_codegen_set_debug_model(lto_code_gen_t) </pre>
- Which kind of position independence is set with: <pre>
- lto_codegen_set_pic_model(lto_code_gen_t) </pre>
- And each symbol that is referenced by a native object file or otherwise
- must not be optimized away is set with: <pre>
- lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*)</pre>
- After all these settings are done, the linker requests that a native
- object file be created from the modules with the settings using:
- lto_codegen_compile(lto_code_gen_t, size*)</pre>
- which returns a pointer to a buffer containing the generated native
- object file. The linker then parses that and links it with the rest
- of the native object files.
+
+<p>Once the linker has loaded each non-native object files into an
+<tt>lto_module_t</tt>, it can request libLTO to process them all and
+generate a native object file. This is done in a couple of steps.
+First, a code generator is created with:</p>
+
+<pre class="doc_code">lto_codegen_create()</pre>
+
+<p>Then, each non-native object file is added to the code generator with:</p>
+
+<pre class="doc_code">
+lto_codegen_add_module(lto_code_gen_t, lto_module_t)
+</pre>
+
+<p>The linker then has the option of setting some codegen options. Whether or
+not to generate DWARF debug info is set with:</p>
+
+<pre class="doc_code">lto_codegen_set_debug_model(lto_code_gen_t)</pre>
+
+<p>Which kind of position independence is set with:</p>
+
+<pre class="doc_code">lto_codegen_set_pic_model(lto_code_gen_t) </pre>
+
+<p>And each symbol that is referenced by a native object file or otherwise must
+not be optimized away is set with:</p>
+
+<pre class="doc_code">
+lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*)
+</pre>
+
+<p>After all these settings are done, the linker requests that a native object
+file be created from the modules with the settings using:</p>
+
+<pre class="doc_code">lto_codegen_compile(lto_code_gen_t, size*)</pre>
+
+<p>which returns a pointer to a buffer containing the generated native
+object file. The linker then parses that and links it with the rest
+of the native object files.</p>
+
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
<a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
Devang Patel and Nick Kledzik<br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
projects / oota-llvm.git / blobdiff