gccint: LTO object file layout
1
1 25.2 LTO file sections
1 ======================
1
1 LTO information is stored in several ELF sections inside object files.
1 Data structures and enum codes for sections are defined in
1 'lto-streamer.h'.
1
1 These sections are emitted from 'lto-streamer-out.c' and mapped in all
1 at once from 'lto/lto.c':'lto_file_read'. The individual functions
1 dealing with the reading/writing of each section are described below.
1
1 * Command line options ('.gnu.lto_.opts')
1
1 This section contains the command line options used to generate the
1 object files. This is used at link time to determine the
1 optimization level and other settings when they are not explicitly
1 specified at the linker command line.
1
1 Currently, GCC does not support combining LTO object files compiled
1 with different set of the command line options into a single
1 binary. At link time, the options given on the command line and
1 the options saved on all the files in a link-time set are applied
1 globally. No attempt is made at validating the combination of
1 flags (other than the usual validation done by option processing).
1 This is implemented in 'lto/lto.c':'lto_read_all_file_options'.
1
1 * Symbol table ('.gnu.lto_.symtab')
1
1 This table replaces the ELF symbol table for functions and
1 variables represented in the LTO IL. Symbols used and exported by
1 the optimized assembly code of "fat" objects might not match the
1 ones used and exported by the intermediate code. This table is
1 necessary because the intermediate code is less optimized and thus
1 requires a separate symbol table.
1
1 Additionally, the binary code in the "fat" object will lack a call
1 to a function, since the call was optimized out at compilation time
1 after the intermediate language was streamed out. In some special
1 cases, the same optimization may not happen during link-time
1 optimization. This would lead to an undefined symbol if only one
1 symbol table was used.
1
1 The symbol table is emitted in
1 'lto-streamer-out.c':'produce_symtab'.
1
1 * Global declarations and types ('.gnu.lto_.decls')
1
1 This section contains an intermediate language dump of all
1 declarations and types required to represent the callgraph, static
1 variables and top-level debug info.
1
1 The contents of this section are emitted in
1 'lto-streamer-out.c':'produce_asm_for_decls'. Types and symbols
1 are emitted in a topological order that preserves the sharing of
1 pointers when the file is read back in
1 ('lto.c':'read_cgraph_and_symbols').
1
1 * The callgraph ('.gnu.lto_.cgraph')
1
1 This section contains the basic data structure used by the GCC
1 inter-procedural optimization infrastructure. This section stores
1 an annotated multi-graph which represents the functions and call
1 sites as well as the variables, aliases and top-level 'asm'
1 statements.
1
1 This section is emitted in 'lto-streamer-out.c':'output_cgraph' and
1 read in 'lto-cgraph.c':'input_cgraph'.
1
1 * IPA references ('.gnu.lto_.refs')
1
1 This section contains references between function and static
1 variables. It is emitted by 'lto-cgraph.c':'output_refs' and read
1 by 'lto-cgraph.c':'input_refs'.
1
1 * Function bodies ('.gnu.lto_.function_body.<name>')
1
1 This section contains function bodies in the intermediate language
1 representation. Every function body is in a separate section to
1 allow copying of the section independently to different object
1 files or reading the function on demand.
1
1 Functions are emitted in 'lto-streamer-out.c':'output_function' and
1 read in 'lto-streamer-in.c':'input_function'.
1
1 * Static variable initializers ('.gnu.lto_.vars')
1
1 This section contains all the symbols in the global variable pool.
1 It is emitted by 'lto-cgraph.c':'output_varpool' and read in
1 'lto-cgraph.c':'input_cgraph'.
1
1 * Summaries and optimization summaries used by IPA passes
1 ('.gnu.lto_.<xxx>', where '<xxx>' is one of 'jmpfuncs', 'pureconst'
1 or 'reference')
1
1 These sections are used by IPA passes that need to emit summary
1 information during LTO generation to be read and aggregated at link
1 time. Each pass is responsible for implementing two pass manager
1 hooks: one for writing the summary and another for reading it in.
1 The format of these sections is entirely up to each individual
1 pass. The only requirement is that the writer and reader hooks
1 agree on the format.
1