In other cases, the linker will simply ignore `PHDRS'. This is the syntax of the `PHDRS' command. The words `PHDRS', `FILEHDR', `AT', and `FLAGS' are keywords. PHDRS { NAME TYPE [ FILEHDR ] [ PHDRS ] [ AT ( ADDRESS ) ] [ FLAGS ( FLAGS ) ] ; } The NAME is used only for reference in the `SECTIONS' command of the linker script. It is not put into the output file. Program header names are stored in a separate name space, and will not conflict with symbol names, file names, or section names. Each program header must have a distinct name. The headers are processed in order and it is usual for them to map to sections in ascending load address order. Certain program header types describe segments of memory which the system loader will load from the file. In the linker script, you specify the contents of these segments by placing allocatable output sections in the segments. You use the `:PHDR' output section attribute to place a section in a particular segment. *Note Output Section Phdr::. It is normal to put certain sections in more than one segment. This merely implies that one segment of memory contains another. You may repeat `:PHDR', using it once for each segment which should contain the section. If you place a section in one or more segments using `:PHDR', then the linker will place all subsequent allocatable sections which do not specify `:PHDR' in the same segments. This is for convenience, since generally a whole set of contiguous sections will be placed in a single segment. You can use `:NONE' to override the default segment and tell the linker to not put the section in any segment at all. You may use the `FILEHDR' and `PHDRS' keywords after the program header type to further describe the contents of the segment. The `FILEHDR' keyword means that the segment should include the ELF file header. The `PHDRS' keyword means that the segment should include the ELF program headers themselves. If applied to a loadable segment (`PT_LOAD'), all prior loadable segments must have one of these keywords. The TYPE may be one of the following. The numbers indicate the value of the keyword. `PT_NULL' (0) Indicates an unused program header. `PT_LOAD' (1) Indicates that this program header describes a segment to be loaded from the file. `PT_DYNAMIC' (2) Indicates a segment where dynamic linking information can be found. `PT_INTERP' (3) Indicates a segment where the name of the program interpreter may be found. `PT_NOTE' (4) Indicates a segment holding note information. `PT_SHLIB' (5) A reserved program header type, defined but not specified by the ELF ABI. `PT_PHDR' (6) Indicates a segment where the program headers may be found. EXPRESSION An expression giving the numeric type of the program header. This may be used for types not defined above. You can specify that a segment should be loaded at a particular address in memory by using an `AT' expression. This is identical to the `AT' command used as an output section attribute (*note Output Section LMA::). The `AT' command for a program header overrides the output section attribute. The linker will normally set the segment flags based on the sections which comprise the segment. You may use the `FLAGS' keyword to explicitly specify the segment flags. The value of FLAGS must be an integer. It is used to set the `p_flags' field of the program header. Here is an example of `PHDRS'. This shows a typical set of program headers used on a native ELF system. PHDRS { headers PT_PHDR PHDRS ; interp PT_INTERP ; text PT_LOAD FILEHDR PHDRS ; data PT_LOAD ; dynamic PT_DYNAMIC ; } SECTIONS { . = SIZEOF_HEADERS; .interp : { *(.interp) } :text :interp .text : { *(.text) } :text .rodata : { *(.rodata) } /* defaults to :text */ ... . = . + 0x1000; /* move to a new page in memory */ .data : { *(.data) } :data .dynamic : { *(.dynamic) } :data :dynamic ... }  File: ld.info, Node: VERSION, Next: Expressions, Prev: PHDRS, Up: Scripts 3.9 VERSION Command =================== The linker supports symbol versions when using ELF. Symbol versions are only useful when using shared libraries. The dynamic linker can use symbol versions to select a specific version of a function when it runs a program that may have been linked against an earlier version of the shared library. You can include a version script directly in the main linker script, or you can supply the version script as an implicit linker script. You can also use the `--version-script' linker option. The syntax of the `VERSION' command is simply VERSION { version-script-commands } The format of the version script commands is identical to that used by Sun's linker in Solaris 2.5. The version script defines a tree of version nodes. You specify the node names and interdependencies in the version script. You can specify which symbols are bound to which version nodes, and you can reduce a specified set of symbols to local scope so that they are not globally visible outside of the shared library. The easiest way to demonstrate the version script language is with a few examples. VERS_1.1 { global: foo1; local: old*; original*; new*; }; VERS_1.2 { foo2; } VERS_1.1; VERS_2.0 { bar1; bar2; extern "C++" { ns::*; "f(int, double)"; }; } VERS_1.2; This example version script defines three version nodes. The first version node defined is `VERS_1.1'; it has no other dependencies. The script binds the symbol `foo1' to `VERS_1.1'. It reduces a number of symbols to local scope so that they are not visible outside of the shared library; this is done using wildcard patterns, so that any symbol whose name begins with `old', `original', or `new' is matched. The wildcard patterns available are the same as those used in the shell when matching filenames (also known as "globbing"). However, if you specify the symbol name inside double quotes, then the name is treated as literal, rather than as a glob pattern. Next, the version script defines node `VERS_1.2'. This node depends upon `VERS_1.1'. The script binds the symbol `foo2' to the version node `VERS_1.2'. Finally, the version script defines node `VERS_2.0'. This node depends upon `VERS_1.2'. The scripts binds the symbols `bar1' and `bar2' are bound to the version node `VERS_2.0'. When the linker finds a symbol defined in a library which is not specifically bound to a version node, it will effectively bind it to an unspecified base version of the library. You can bind all otherwise unspecified symbols to a given version node by using `global: *;' somewhere in the version script. Note that it's slightly crazy to use wildcards in a global spec except on the last version node. Global wildcards elsewhere run the risk of accidentally adding symbols to the set exported for an old version. That's wrong since older versions ought to have a fixed set of symbols. The names of the version nodes have no specific meaning other than what they might suggest to the person reading them. The `2.0' version could just as well have appeared in between `1.1' and `1.2'. However, this would be a confusing way to write a version script. Node name can be omitted, provided it is the only version node in the version script. Such version script doesn't assign any versions to symbols, only selects which symbols will be globally visible out and which won't. { global: foo; bar; local: *; }; When you link an application against a shared library that has versioned symbols, the application itself knows which version of each symbol it requires, and it also knows which version nodes it needs from each shared library it is linked against. Thus at runtime, the dynamic loader can make a quick check to make sure that the libraries you have linked against do in fact supply all of the version nodes that the application will need to resolve all of the dynamic symbols. In this way it is possible for the dynamic linker to know with certainty that all external symbols that it needs will be resolvable without having to search for each symbol reference. The symbol versioning is in effect a much more sophisticated way of doing minor version checking that SunOS does. The fundamental problem that is being addressed here is that typically references to external functions are bound on an as-needed basis, and are not all bound when the application starts up. If a shared library is out of date, a required interface may be missing; when the application tries to use that interface, it may suddenly and unexpectedly fail. With symbol versioning, the user will get a warning when they start their program if the libraries being used with the application are too old. There are several GNU extensions to Sun's versioning approach. The first of these is the ability to bind a symbol to a version node in the source file where the symbol is defined instead of in the versioning script. This was done mainly to reduce the burden on the library maintainer. You can do this by putting something like: __asm__(".symver original_foo,foo@VERS_1.1"); in the C source file. This renames the function `original_foo' to be an alias for `foo' bound to the version node `VERS_1.1'. The `local:' directive can be used to prevent the symbol `original_foo' from being exported. A `.symver' directive takes precedence over a version script. The second GNU extension is to allow multiple versions of the same function to appear in a given shared library. In this way you can make an incompatible change to an interface without increasing the major version number of the shared library, while still allowing applications linked against the old interface to continue to function. To do this, you must use multiple `.symver' directives in the source file. Here is an example: __asm__(".symver original_foo,foo@"); __asm__(".symver old_foo,foo@VERS_1.1"); __asm__(".symver old_foo1,foo@VERS_1.2"); __asm__(".symver new_foo,foo@@VERS_2.0"); In this example, `foo@' represents the symbol `foo' bound to the unspecified base version of the symbol. The source file that contains this example would define 4 C functions: `original_foo', `old_foo', `old_foo1', and `new_foo'. When you have multiple definitions of a given symbol, there needs to be some way to specify a default version to which external references to this symbol will be bound. You can do this with the `foo@@VERS_2.0' type of `.symver' directive. You can only declare one version of a symbol as the default in this manner; otherwise you would effectively have multiple definitions of the same symbol. If you wish to bind a reference to a specific version of the symbol within the shared library, you can use the aliases of convenience (i.e., `old_foo'), or you can use the `.symver' directive to specifically bind to an external version of the function in question. You can also specify the language in the version script: VERSION extern "lang" { version-script-commands } The supported `lang's are `C', `C++', and `Java'. The linker will iterate over the list of symbols at the link time and demangle them according to `lang' before matching them to the patterns specified in `version-script-commands'. The default `lang' is `C'. Demangled names may contains spaces and other special characters. As described above, you can use a glob pattern to match demangled names, or you can use a double-quoted string to match the string exactly. In the latter case, be aware that minor differences (such as differing whitespace) between the version script and the demangler output will cause a mismatch. As the exact string generated by the demangler might change in the future, even if the mangled name does not, you should check that all of your version directives are behaving as you expect when you upgrade.  File: ld.info, Node: Expressions, Next: Implicit Linker Scripts, Prev: VERSION, Up: Scripts 3.10 Expressions in Linker Scripts ================================== The syntax for expressions in the linker script language is identical to that of C expressions. All expressions are evaluated as integers. All expressions are evaluated in the same size, which is 32 bits if both the host and target are 32 bits, and is otherwise 64 bits. You can use and set symbol values in expressions. The linker defines several special purpose builtin functions for use in expressions. * Menu: * Constants:: Constants * Symbolic Constants:: Symbolic constants * Symbols:: Symbol Names * Orphan Sections:: Orphan Sections * Location Counter:: The Location Counter * Operators:: Operators * Evaluation:: Evaluation * Expression Section:: The Section of an Expression * Builtin Functions:: Builtin Functions  File: ld.info, Node: Constants, Next: Symbolic Constants, Up: Expressions 3.10.1 Constants ---------------- All constants are integers. As in C, the linker considers an integer beginning with `0' to be octal, and an integer beginning with `0x' or `0X' to be hexadecimal. Alternatively the linker accepts suffixes of `h' or `H' for hexadeciaml, `o' or `O' for octal, `b' or `B' for binary and `d' or `D' for decimal. Any integer value without a prefix or a suffix is considered to be decimal. In addition, you can use the suffixes `K' and `M' to scale a constant by `1024' or `1024*1024' respectively. For example, the following all refer to the same quantity: _fourk_1 = 4K; _fourk_2 = 4096; _fourk_3 = 0x1000; _fourk_4 = 10000o; Note - the `K' and `M' suffixes cannot be used in conjunction with the base suffixes mentioned above.  File: ld.info, Node: Symbolic Constants, Next: Symbols, Prev: Constants, Up: Expressions 3.10.2 Symbolic Constants ------------------------- It is possible to refer to target specific constants via the use of the `CONSTANT(NAME)' operator, where NAME is one of: `MAXPAGESIZE' The target's maximum page size. `COMMONPAGESIZE' The target's default page size. So for example: .text ALIGN (CONSTANT (MAXPAGESIZE)) : { *(.text) } will create a text section aligned to the largest page boundary supported by the target.  File: ld.info, Node: Symbols, Next: Orphan Sections, Prev: Symbolic Constants, Up: Expressions 3.10.3 Symbol Names ------------------- Unless quoted, symbol names start with a letter, underscore, or period and may include letters, digits, underscores, periods, and hyphens. Unquoted symbol names must not conflict with any keywords. You can specify a symbol which contains odd characters or has the same name as a keyword by surrounding the symbol name in double quotes: "SECTION" = 9; "with a space" = "also with a space" + 10; Since symbols can contain many non-alphabetic characters, it is safest to delimit symbols with spaces. For example, `A-B' is one symbol, whereas `A - B' is an expression involving subtraction.  File: ld.info, Node: Orphan Sections, Next: Location Counter, Prev: Symbols, Up: Expressions 3.10.4 Orphan Sections ---------------------- Orphan sections are sections present in the input files which are not explicitly placed into the output file by the linker script. The linker will still copy these sections into the output file, but it has to guess as to where they should be placed. The linker uses a simple heuristic to do this. It attempts to place orphan sections after non-orphan sections of the same attribute, such as code vs data, loadable vs non-loadable, etc. If there is not enough room to do this then it places at the end of the file. For ELF targets, the attribute of the section includes section type as well as section flag. If an orphaned section's name is representable as a C identifier then the linker will automatically *note PROVIDE:: two symbols: __start_SECNAME and __end_SECNAME, where SECNAME is the name of the section. These indicate the start address and end address of the orphaned section respectively. Note: most section names are not representable as C identifiers because they contain a `.' character.  File: ld.info, Node: Location Counter, Next: Operators, Prev: Orphan Sections, Up: Expressions 3.10.5 The Location Counter --------------------------- The special linker variable "dot" `.' always contains the current output location counter. Since the `.' always refers to a location in an output section, it may only appear in an expression within a `SECTIONS' command. The `.' symbol may appear anywhere that an ordinary symbol is allowed in an expression. Assigning a value to `.' will cause the location counter to be moved. This may be used to create holes in the output section. The location counter may not be moved backwards inside an output section, and may not be moved backwards outside of an output section if so doing creates areas with overlapping LMAs. SECTIONS { output : { file1(.text) . = . + 1000; file2(.text) . += 1000; file3(.text) } = 0x12345678; } In the previous example, the `.text' section from `file1' is located at the beginning of the output section `output'. It is followed by a 1000 byte gap. Then the `.text' section from `file2' appears, also with a 1000 byte gap following before the `.text' section from `file3'. The notation `= 0x12345678' specifies what data to write in the gaps (*note Output Section Fill::). Note: `.' actually refers to the byte offset from the start of the current containing object. Normally this is the `SECTIONS' statement, whose start address is 0, hence `.' can be used as an absolute address. If `.' is used inside a section description however, it refers to the byte offset from the start of that section, not an absolute address. Thus in a script like this: SECTIONS { . = 0x100 .text: { *(.text) . = 0x200 } . = 0x500 .data: { *(.data) . += 0x600 } } The `.text' section will be assigned a starting address of 0x100 and a size of exactly 0x200 bytes, even if there is not enough data in the `.text' input sections to fill this area. (If there is too much data, an error will be produced because this would be an attempt to move `.' backwards). The `.data' section will start at 0x500 and it will have an extra 0x600 bytes worth of space after the end of the values from the `.data' input sections and before the end of the `.data' output section itself. Setting symbols to the value of the location counter outside of an output section statement can result in unexpected values if the linker needs to place orphan sections. For example, given the following: SECTIONS { start_of_text = . ; .text: { *(.text) } end_of_text = . ; start_of_data = . ; .data: { *(.data) } end_of_data = . ; } If the linker needs to place some input section, e.g. `.rodata', not mentioned in the script, it might choose to place that section between `.text' and `.data'. You might think the linker should place `.rodata' on the blank line in the above script, but blank lines are of no particular significance to the linker. As well, the linker doesn't associate the above symbol names with their sections. Instead, it assumes that all assignments or other statements belong to the previous output section, except for the special case of an assignment to `.'. I.e., the linker will place the orphan `.rodata' section as if the script was written as follows: SECTIONS { start_of_text = . ; .text: { *(.text) } end_of_text = . ; start_of_data = . ; .rodata: { *(.rodata) } .data: { *(.data) } end_of_data = . ; } This may or may not be the script author's intention for the value of `start_of_data'. One way to influence the orphan section placement is to assign the location counter to itself, as the linker assumes that an assignment to `.' is setting the start address of a following output section and thus should be grouped with that section. So you could write: SECTIONS { start_of_text = . ; .text: { *(.text) } end_of_text = . ; . = . ; start_of_data = . ; .data: { *(.data) } end_of_data = . ; } Now, the orphan `.rodata' section will be placed between `end_of_text' and `start_of_data'.  File: ld.info, Node: Operators, Next: Evaluation, Prev: Location Counter, Up: Expressions 3.10.6 Operators ---------------- The linker recognizes the standard C set of arithmetic operators, with the standard bindings and precedence levels: precedence associativity Operators Notes (highest) 1 left ! - ~ (1) 2 left * / % 3 left + - 4 left >> << 5 left == != > < <= >= 6 left & 7 left | 8 left && 9 left || 10 right ? : 11 right &= += -= *= /= (2) (lowest) Notes: (1) Prefix operators (2) *Note Assignments::.  File: ld.info, Node: Evaluation, Next: Expression Section, Prev: Operators, Up: Expressions 3.10.7 Evaluation ----------------- The linker evaluates expressions lazily. It only computes the value of an expression when absolutely necessary. The linker needs some information, such as the value of the start address of the first section, and the origins and lengths of memory regions, in order to do any linking at all. These values are computed as soon as possible when the linker reads in the linker script. However, other values (such as symbol values) are not known or needed until after storage allocation. Such values are evaluated later, when other information (such as the sizes of output sections) is available for use in the symbol assignment expression. The sizes of sections cannot be known until after allocation, so assignments dependent upon these are not performed until after allocation. Some expressions, such as those depending upon the location counter `.', must be evaluated during section allocation. If the result of an expression is required, but the value is not available, then an error results. For example, a script like the following SECTIONS { .text 9+this_isnt_constant : { *(.text) } } will cause the error message `non constant expression for initial address'.  File: ld.info, Node: Expression Section, Next: Builtin Functions, Prev: Evaluation, Up: Expressions 3.10.8 The Section of an Expression ----------------------------------- Addresses and symbols may be section relative, or absolute. A section relative symbol is relocatable. If you request relocatable output using the `-r' option, a further link operation may change the value of a section relative symbol. On the other hand, an absolute symbol will retain the same value throughout any further link operations. Some terms in linker expressions are addresses. This is true of section relative symbols and for builtin functions that return an address, such as `ADDR', `LOADADDR', `ORIGIN' and `SEGMENT_START'. Other terms are simply numbers, or are builtin functions that return a non-address value, such as `LENGTH'. When the linker evaluates an expression, the result depends on where the expression is located in a linker script. Expressions appearing outside an output section definitions are evaluated with all terms first being converted to absolute addresses before applying operators, and evaluate to an absolute address result. Expressions appearing inside an output section definition are evaluated with more complex rules, but the aim is to treat terms as relative addresses and produce a relative address result. In particular, an assignment of a number to a symbol results in a symbol relative to the output section with an offset given by the number. So, in the following simple example, SECTIONS { . = 0x100; __executable_start = 0x100; .data : { . = 0x10; __data_start = 0x10; *(.data) } ... } both `.' and `__executable_start' are set to the absolute address 0x100 in the first two assignments, then both `.' and `__data_start' are set to 0x10 relative to the `.data' section in the second two assignments. For expressions appearing inside an output section definition involving numbers, relative addresses and absolute addresses, ld follows these rules to evaluate terms: * Unary operations on a relative address, and binary operations on two relative addresses in the same section or between one relative address and a number, apply the operator to the offset part of the address(es). * Unary operations on an absolute address, and binary operations on one or more absolute addresses or on two relative addresses not in the same section, first convert any non-absolute term to an absolute address before applying the operator. The result section of each sub-expression is as follows: * An operation involving only numbers results in a number. * The result of comparisons, `&&' and `||' is also a number. * The result of other operations on relative addresses (after above conversions) is a relative address in the same section as the operand(s). * The result of other operations on absolute addresses (after above conversions) is an absolute address. You can use the builtin function `ABSOLUTE' to force an expression to be absolute when it would otherwise be relative. For example, to create an absolute symbol set to the address of the end of the output section `.data': SECTIONS { .data : { *(.data) _edata = ABSOLUTE(.); } } If `ABSOLUTE' were not used, `_edata' would be relative to the `.data' section. Using `LOADADDR' also forces an expression absolute, since this particular builtin function returns an absolute address.  File: ld.info, Node: Builtin Functions, Prev: Expression Section, Up: Expressions 3.10.9 Builtin Functions ------------------------ The linker script language includes a number of builtin functions for use in linker script expressions. `ABSOLUTE(EXP)' Return the absolute (non-relocatable, as opposed to non-negative) value of the expression EXP. Primarily useful to assign an absolute value to a symbol within a section definition, where symbol values are normally section relative. *Note Expression Section::. `ADDR(SECTION)' Return the address (VMA) of the named SECTION. Your script must previously have defined the location of that section. In the following example, `start_of_output_1', `symbol_1' and `symbol_2' are assigned equivalent values, except that `symbol_1' will be relative to the `.output1' section while the other two will be absolute: SECTIONS { ... .output1 : { start_of_output_1 = ABSOLUTE(.); ... } .output : { symbol_1 = ADDR(.output1); symbol_2 = start_of_output_1; } ... } `ALIGN(ALIGN)' `ALIGN(EXP,ALIGN)' Return the location counter (`.') or arbitrary expression aligned to the next ALIGN boundary. The single operand `ALIGN' doesn't change the value of the location counter--it just does arithmetic on it. The two operand `ALIGN' allows an arbitrary expression to be aligned upwards (`ALIGN(ALIGN)' is equivalent to `ALIGN(., ALIGN)'). Here is an example which aligns the output `.data' section to the next `0x2000' byte boundary after the preceding section and sets a variable within the section to the next `0x8000' boundary after the input sections: SECTIONS { ... .data ALIGN(0x2000): { *(.data) variable = ALIGN(0x8000); } ... } The first use of `ALIGN' in this example specifies the location of a section because it is used as the optional ADDRESS attribute of a section definition (*note Output Section Address::). The second use of `ALIGN' is used to defines the value of a symbol. The builtin function `NEXT' is closely related to `ALIGN'. `ALIGNOF(SECTION)' Return the alignment in bytes of the named SECTION, if that section has been allocated. If the section has not been allocated when this is evaluated, the linker will report an error. In the following example, the alignment of the `.output' section is stored as the first value in that section. SECTIONS{ ... .output { LONG (ALIGNOF (.output)) ... } ... } `BLOCK(EXP)' This is a synonym for `ALIGN', for compatibility with older linker scripts. It is most often seen when setting the address of an output section. `DATA_SEGMENT_ALIGN(MAXPAGESIZE, COMMONPAGESIZE)' This is equivalent to either (ALIGN(MAXPAGESIZE) + (. & (MAXPAGESIZE - 1))) or (ALIGN(MAXPAGESIZE) + (. & (MAXPAGESIZE - COMMONPAGESIZE))) depending on whether the latter uses fewer COMMONPAGESIZE sized pages for the data segment (area between the result of this expression and `DATA_SEGMENT_END') than the former or not. If the latter form is used, it means COMMONPAGESIZE bytes of runtime memory will be saved at the expense of up to COMMONPAGESIZE wasted bytes in the on-disk file. This expression can only be used directly in `SECTIONS' commands, not in any output section descriptions and only once in the linker script. COMMONPAGESIZE should be less or equal to MAXPAGESIZE and should be the system page size the object wants to be optimized for (while still working on system page sizes up to MAXPAGESIZE). Example: . = DATA_SEGMENT_ALIGN(0x10000, 0x2000); `DATA_SEGMENT_END(EXP)' This defines the end of data segment for `DATA_SEGMENT_ALIGN' evaluation purposes. . = DATA_SEGMENT_END(.); `DATA_SEGMENT_RELRO_END(OFFSET, EXP)' This defines the end of the `PT_GNU_RELRO' segment when `-z relro' option is used. Second argument is returned. When `-z relro' option is not present, `DATA_SEGMENT_RELRO_END' does nothing, otherwise `DATA_SEGMENT_ALIGN' is padded so that EXP + OFFSET is aligned to the most commonly used page boundary for particular target. If present in the linker script, it must always come in between `DATA_SEGMENT_ALIGN' and `DATA_SEGMENT_END'. . = DATA_SEGMENT_RELRO_END(24, .); `DEFINED(SYMBOL)' Return 1 if SYMBOL is in the linker global symbol table and is defined before the statement using DEFINED in the script, otherwise return 0. You can use this function to provide default values for symbols. For example, the following script fragment shows how to set a global symbol `begin' to the first location in the `.text' section--but if a symbol called `begin' already existed, its value is preserved: SECTIONS { ... .text : { begin = DEFINED(begin) ? begin : . ; ... } ... } `LENGTH(MEMORY)' Return the length of the memory region named MEMORY. `LOADADDR(SECTION)' Return the absolute LMA of the named SECTION. (*note Output Section LMA::). `MAX(EXP1, EXP2)' Returns the maximum of EXP1 and EXP2. `MIN(EXP1, EXP2)' Returns the minimum of EXP1 and EXP2. `NEXT(EXP)' Return the next unallocated address that is a multiple of EXP. This function is closely related to `ALIGN(EXP)'; unless you use the `MEMORY' command to define discontinuous memory for the output file, the two functions are equivalent. `ORIGIN(MEMORY)' Return the origin of the memory region named MEMORY. `SEGMENT_START(SEGMENT, DEFAULT)' Return the base address of the named SEGMENT. If an explicit value has been given for this segment (with a command-line `-T' option) that value will be returned; otherwise the value will be DEFAULT. At present, the `-T' command-line option can only be used to set the base address for the "text", "data", and "bss" sections, but you can use `SEGMENT_START' with any segment name. `SIZEOF(SECTION)' Return the size in bytes of the named SECTION, if that section has been allocated. If the section has not been allocated when this is evaluated, the linker will report an error. In the following example, `symbol_1' and `symbol_2' are assigned identical values: SECTIONS{ ... .output { .start = . ; ... .end = . ; } symbol_1 = .end - .start ; symbol_2 = SIZEOF(.output); ... } `SIZEOF_HEADERS' `sizeof_headers' Return the size in bytes of the output file's headers. This is information which appears at the start of the output file. You can use this number when setting the start address of the first section, if you choose, to facilitate paging. When producing an ELF output file, if the linker script uses the `SIZEOF_HEADERS' builtin function, the linker must compute the number of program headers before it has determined all the section addresses and sizes. If the linker later discovers that it needs additional program headers, it will report an error `not enough room for program headers'. To avoid this error, you must avoid using the `SIZEOF_HEADERS' function, or you must rework your linker script to avoid forcing the linker to use additional program headers, or you must define the program headers yourself using the `PHDRS' command (*note PHDRS::).  File: ld.info, Node: Implicit Linker Scripts, Prev: Expressions, Up: Scripts 3.11 Implicit Linker Scripts ============================ If you specify a linker input file which the linker can not recognize as an object file or an archive file, it will try to read the file as a linker script. If the file can not be parsed as a linker script, the linker will report an error. An implicit linker script will not replace the default linker script. Typically an implicit linker script would contain only symbol assignments, or the `INPUT', `GROUP', or `VERSION' commands. Any input files read because of an implicit linker script will be read at the position in the command line where the implicit linker script was read. This can affect archive searching.  File: ld.info, Node: Machine Dependent, Next: BFD, Prev: Scripts, Up: Top 4 Machine Dependent Features **************************** `ld' has additional features on some platforms; the following sections describe them. Machines where `ld' has no additional functionality are not listed. * Menu: * H8/300:: `ld' and the H8/300 * i960:: `ld' and the Intel 960 family * ARM:: `ld' and the ARM family * HPPA ELF32:: `ld' and HPPA 32-bit ELF * M68K:: `ld' and the Motorola 68K family * MMIX:: `ld' and MMIX * MSP430:: `ld' and MSP430 * M68HC11/68HC12:: `ld' and the Motorola 68HC11 and 68HC12 families * PowerPC ELF32:: `ld' and PowerPC 32-bit ELF Support * PowerPC64 ELF64:: `ld' and PowerPC64 64-bit ELF Support * SPU ELF:: `ld' and SPU ELF Support * TI COFF:: `ld' and TI COFF * WIN32:: `ld' and WIN32 (cygwin/mingw) * Xtensa:: `ld' and Xtensa Processors  File: ld.info, Node: H8/300, Next: i960, Up: Machine Dependent 4.1 `ld' and the H8/300 ======================= For the H8/300, `ld' can perform these global optimizations when you specify the `--relax' command-line option. _relaxing address modes_ `ld' finds all `jsr' and `jmp' instructions whose targets are within eight bits, and turns them into eight-bit program-counter relative `bsr' and `bra' instructions, respectively. _synthesizing instructions_ `ld' finds all `mov.b' instructions which use the sixteen-bit absolute address form, but refer to the top page of memory, and changes them to use the eight-bit address form. (That is: the linker turns `mov.b `@'AA:16' into `mov.b `@'AA:8' whenever the address AA is in the top page of memory). _bit manipulation instructions_ `ld' finds all bit manipulation instructions like `band, bclr, biand, bild, bior, bist, bixor, bld, bnot, bor, bset, bst, btst, bxor' which use 32 bit and 16 bit absolute address form, but refer to the top page of memory, and changes them to use the 8 bit address form. (That is: the linker turns `bset #xx:3,`@'AA:32' into `bset #xx:3,`@'AA:8' whenever the address AA is in the top page of memory). _system control instructions_ `ld' finds all `ldc.w, stc.w' instructions which use the 32 bit absolute address form, but refer to the top page of memory, and changes them to use 16 bit address form. (That is: the linker turns `ldc.w `@'AA:32,ccr' into `ldc.w `@'AA:16,ccr' whenever the address AA is in the top page of memory).  File: ld.info, Node: i960, Next: ARM, Prev: H8/300, Up: Machine Dependent 4.2 `ld' and the Intel 960 Family ================================= You can use the `-AARCHITECTURE' command line option to specify one of the two-letter names identifying members of the 960 family; the option specifies the desired output target, and warns of any incompatible instructions in the input files. It also modifies the linker's search strategy for archive libraries, to support the use of libraries specific to each particular architecture, by including in the search loop names suffixed with the string identifying the architecture. For example, if your `ld' command line included `-ACA' as well as `-ltry', the linker would look (in its built-in search paths, and in any paths you specify with `-L') for a library with the names try libtry.a tryca libtryca.a The first two possibilities would be considered in any event; the last two are due to the use of `-ACA'. You can meaningfully use `-A' more than once on a command line, since the 960 architecture family allows combination of target architectures; each use will add another pair of name variants to search for when `-l' specifies a library. `ld' supports the `--relax' option for the i960 family. If you specify `--relax', `ld' finds all `balx' and `calx' instructions whose targets are within 24 bits, and turns them into 24-bit program-counter relative `bal' and `cal' instructions, respectively. `ld' also turns `cal' instructions into `bal' instructions when it determines that the target subroutine is a leaf routine (that is, the target subroutine does not itself call any subroutines). The `--fix-cortex-a8' switch enables a link-time workaround for an erratum in certain Cortex-A8 processors. The workaround is enabled by default if you are targeting the ARM v7-A architecture profile. It can be enabled otherwise by specifying `--fix-cortex-a8', or disabled unconditionally by specifying `--no-fix-cortex-a8'. The erratum only affects Thumb-2 code. Please contact ARM for further details. The `--no-merge-exidx-entries' switch disables the merging of adjacent exidx entries in debuginfo.  File: ld.info, Node: M68HC11/68HC12, Next: PowerPC ELF32, Prev: MSP430, Up: Machine Dependent 4.3 `ld' and the Motorola 68HC11 and 68HC12 families ==================================================== 4.3.1 Linker Relaxation ----------------------- For the Motorola 68HC11, `ld' can perform these global optimizations when you specify the `--relax' command-line option. _relaxing address modes_ `ld' finds all `jsr' and `jmp' instructions whose targets are within eight bits, and turns them into eight-bit program-counter relative `bsr' and `bra' instructions, respectively. `ld' also looks at all 16-bit extended addressing modes and transforms them in a direct addressing mode when the address is in page 0 (between 0 and 0x0ff). _relaxing gcc instruction group_ When `gcc' is called with `-mrelax', it can emit group of instructions that the linker can optimize to use a 68HC11 direct addressing mode. These instructions consists of `bclr' or `bset' instructions. 4.3.2 Trampoline Generation --------------------------- For 68HC11 and 68HC12, `ld' can generate trampoline code to call a far function using a normal `jsr' instruction. The linker will also change the relocation to some far function to use the trampoline address instead of the function address. This is typically the case when a pointer to a function is taken. The pointer will in fact point to the function trampoline.  File: ld.info, Node: ARM, Next: HPPA ELF32, Prev: i960, Up: Machine Dependent 4.4 `ld' and the ARM family =========================== For the ARM, `ld' will generate code stubs to allow functions calls between ARM and Thumb code. These stubs only work with code that has been compiled and assembled with the `-mthumb-interwork' command line option. If it is necessary to link with old ARM object files or libraries, which have not been compiled with the -mthumb-interwork option then the `--support-old-code' command line switch should be given to the linker. This will make it generate larger stub functions which will work with non-interworking aware ARM code. Note, however, the linker does not support generating stubs for function calls to non-interworking aware Thumb code. The `--thumb-entry' switch is a duplicate of the generic `--entry' switch, in that it sets the program's starting address. But it also sets the bottom bit of the address, so that it can be branched to using a BX instruction, and the program will start executing in Thumb mode straight away. The `--use-nul-prefixed-import-tables' switch is specifying, that the import tables idata4 and idata5 have to be generated with a zero elememt prefix for import libraries. This is the old style to generate import tables. By default this option is turned off. The `--be8' switch instructs `ld' to generate BE8 format executables. This option is only valid when linking big-endian objects. The resulting image will contain big-endian data and little-endian code. The `R_ARM_TARGET1' relocation is typically used for entries in the `.init_array' section. It is interpreted as either `R_ARM_REL32' or `R_ARM_ABS32', depending on the target. The `--target1-rel' and `--target1-abs' switches override the default. The `--target2=type' switch overrides the default definition of the `R_ARM_TARGET2' relocation. Valid values for `type', their meanings, and target defaults are as follows: `rel' `R_ARM_REL32' (arm*-*-elf, arm*-*-eabi) `abs' `R_ARM_ABS32' (arm*-*-symbianelf) `got-rel' `R_ARM_GOT_PREL' (arm*-*-linux, arm*-*-*bsd) The `R_ARM_V4BX' relocation (defined by the ARM AAELF specification) enables objects compiled for the ARMv4 architecture to be interworking-safe when linked with other objects compiled for ARMv4t, but also allows pure ARMv4 binaries to be built from the same ARMv4 objects. In the latter case, the switch `--fix-v4bx' must be passed to the linker, which causes v4t `BX rM' instructions to be rewritten as `MOV PC,rM', since v4 processors do not have a `BX' instruction. In the former case, the switch should not be used, and `R_ARM_V4BX' relocations are ignored. Replace `BX rM' instructions identified by `R_ARM_V4BX' relocations with a branch to the following veneer: TST rM, #1 MOVEQ PC, rM BX Rn This allows generation of libraries/applications that work on ARMv4 cores and are still interworking safe. Note that the above veneer clobbers the condition flags, so may cause incorrect progrm behavior in rare cases. The `--use-blx' switch enables the linker to use ARM/Thumb BLX instructions (available on ARMv5t and above) in various situations. Currently it is used to perform calls via the PLT from Thumb code using BLX rather than using BX and a mode-switching stub before each PLT entry. This should lead to such calls executing slightly faster. This option is enabled implicitly for SymbianOS, so there is no need to specify it if you are using that target. The `--vfp11-denorm-fix' switch enables a link-time workaround for a bug in certain VFP11 coprocessor hardware, which sometimes allows instructions with denorm operands (which must be handled by support code) to have those operands overwritten by subsequent instructions before the support code can read the intended values. The bug may be avoided in scalar mode if you allow at least one intervening instruction between a VFP11 instruction which uses a register and another instruction which writes to the same register, or at least two intervening instructions if vector mode is in use. The bug only affects full-compliance floating-point mode: you do not need this workaround if you are using "runfast" mode. Please contact ARM for further details. If you know you are using buggy VFP11 hardware, you can enable this workaround by specifying the linker option `--vfp-denorm-fix=scalar' if you are using the VFP11 scalar mode only, or `--vfp-denorm-fix=vector' if you are using vector mode (the latter also works for scalar code). The default is `--vfp-denorm-fix=none'. If the workaround is enabled, instructions are scanned for potentially-troublesome sequences, and a veneer is created for each such sequence which may trigger the erratum. The veneer consists of the first instruction of the sequence and a branch back to the subsequent instruction. The original instruction is then replaced with a branch to the veneer. The extra cycles required to call and return from the veneer are sufficient to avoid the erratum in both the scalar and vector cases. The `--no-enum-size-warning' switch prevents the linker from warning when linking object files that specify incompatible EABI enumeration size attributes. For example, with this switch enabled, linking of an object file using 32-bit enumeration values with another using enumeration values fitted into the smallest possible space will not be diagnosed. The `--no-wchar-size-warning' switch prevents the linker from warning when linking object files that specify incompatible EABI `wchar_t' size attributes. For example, with this switch enabled, linking of an object file using 32-bit `wchar_t' values with another using 16-bit `wchar_t' values will not be diagnosed. The `--pic-veneer' switch makes the linker use PIC sequences for ARM/Thumb interworking veneers, even if the rest of the binary is not PIC. This avoids problems on uClinux targets where `--emit-relocs' is used to generate relocatable binaries. The linker will automatically generate and insert small sequences of code into a linked ARM ELF executable whenever an attempt is made to perform a function call to a symbol that is too far away. The placement of these sequences of instructions - called stubs - is controlled by the command line option `--stub-group-size=N'. The placement is important because a poor choice can create a need for duplicate stubs, increasing the code sizw. The linker will try to group stubs together in order to reduce interruptions to the flow of code, but it needs guidance as to how big these groups should be and where they should be placed. The value of `N', the parameter to the `--stub-group-size=' option controls where the stub groups are placed. If it is negative then all stubs are placed after the first branch that needs them. If it is positive then the stubs can be placed either before or after the branches that need them. If the value of `N' is 1 (either +1 or -1) then the linker will choose exactly where to place groups of stubs, using its built in heuristics. A value of `N' greater than 1 (or smaller than -1) tells the linker that a single group of stubs can service at most `N' bytes from the input sections. The default, if `--stub-group-size=' is not specified, is `N = +1'. Farcalls stubs insertion is fully supported for the ARM-EABI target only, because it relies on object files properties not present otherwise.  File: ld.info, Node: HPPA ELF32, Next: M68K, Prev: ARM, Up: Machine Dependent 4.5 `ld' and HPPA 32-bit ELF Support ==================================== When generating a shared library, `ld' will by default generate import stubs suitable for use with a single sub-space application. The `--multi-subspace' switch causes `ld' to generate export stubs, and different (larger) import stubs suitable for use with multiple sub-spaces. Long branch stubs and import/export stubs are placed by `ld' in stub sections located between groups of input sections. `--stub-group-size' specifies the maximum size of a group of input sections handled by one stub section. Since branch offsets are signed, a stub section may serve two groups of input sections, one group before the stub section, and one group after it. However, when using conditional branches that require stubs, it may be better (for branch prediction) that stub sections only serve one group of input sections. A negative value for `N' chooses this scheme, ensuring that branches to stubs always use a negative offset. Two special values of `N' are recognized, `1' and `-1'. These both instruct `ld' to automatically size input section groups for the branch types detected, with the same behaviour regarding stub placement as other positive or negative values of `N' respectively. Note that `--stub-group-size' does not split input sections. A single input section larger than the group size specified will of course create a larger group (of one section). If input sections are too large, it may not be possible for a branch to reach its stub.  File: ld.info, Node: M68K, Next: MMIX, Prev: HPPA ELF32, Up: Machine Dependent 4.6 `ld' and the Motorola 68K family ==================================== The `--got=TYPE' option lets you choose the GOT generation scheme. The choices are `single', `negative', `multigot' and `target'. When `target' is selected the linker chooses the default GOT generation scheme for the current target. `single' tells the linker to generate a single GOT with entries only at non-negative offsets. `negative' instructs the linker to generate a single GOT with entries at both negative and positive offsets. Not all environments support such GOTs. `multigot' allows the linker to generate several GOTs in the output file. All GOT references from a single input object file access the same GOT, but references from different input object files might access different GOTs. Not all environments support such GOTs.  File: ld.info, Node: MMIX, Next: MSP430, Prev: M68K, Up: Machine Dependent 4.7 `ld' and MMIX ================= For MMIX, there is a choice of generating `ELF' object files or `mmo' object files when linking. The simulator `mmix' understands the `mmo' format. The binutils `objcopy' utility can translate between the two formats. There is one special section, the `.MMIX.reg_contents' section. Contents in this section is assumed to correspond to that of global registers, and symbols referring to it are translated to special symbols, equal to registers. In a final link, the start address of the `.MMIX.reg_contents' section corresponds to the first allocated global register multiplied by 8. Register `$255' is not included in this section; it is always set to the program entry, which is at the symbol `Main' for `mmo' files. Global symbols with the prefix `__.MMIX.start.', for example `__.MMIX.start..text' and `__.MMIX.start..data' are special. The default linker script uses these to set the default start address of a section. Initial and trailing multiples of zero-valued 32-bit words in a section, are left out from an mmo file.  File: ld.info, Node: MSP430, Next: M68HC11/68HC12, Prev: MMIX, Up: Machine Dependent 4.8 `ld' and MSP430 =================== For the MSP430 it is possible to select the MPU architecture. The flag `-m [mpu type]' will select an appropriate linker script for selected MPU type. (To get a list of known MPUs just pass `-m help' option to the linker). The linker will recognize some extra sections which are MSP430 specific: ``.vectors'' Defines a portion of ROM where interrupt vectors located. ``.bootloader'' Defines the bootloader portion of the ROM (if applicable). Any code in this section will be uploaded to the MPU. ``.infomem'' Defines an information memory section (if applicable). Any code in this section will be uploaded to the MPU. ``.infomemnobits'' This is the same as the `.infomem' section except that any code in this section will not be uploaded to the MPU. ``.noinit'' Denotes a portion of RAM located above `.bss' section. The last two sections are used by gcc.  File: ld.info, Node: PowerPC ELF32, Next: PowerPC64 ELF64, Prev: M68HC11/68HC12, Up: Machine Dependent 4.9 `ld' and PowerPC 32-bit ELF Support ======================================= Branches on PowerPC processors are limited to a signed 26-bit displacement, which may result in `ld' giving `relocation truncated to fit' errors with very large programs. `--relax' enables the generation of trampolines that can access the entire 32-bit address space. These trampolines are inserted at section boundaries, so may not themselves be reachable if an input section exceeds 33M in size. You may combine `-r' and `--relax' to add trampolines in a partial link. In that case both branches to undefined symbols and inter-section branches are also considered potentially out of range, and trampolines inserted. `--bss-plt' Current PowerPC GCC accepts a `-msecure-plt' option that generates code capable of using a newer PLT and GOT layout that has the security advantage of no executable section ever needing to be writable and no writable section ever being executable. PowerPC `ld' will generate this layout, including stubs to access the PLT, if all input files (including startup and static libraries) were compiled with `-msecure-plt'. `--bss-plt' forces the old BSS PLT (and GOT layout) which can give slightly better performance. `--secure-plt' `ld' will use the new PLT and GOT layout if it is linking new `-fpic' or `-fPIC' code, but does not do so automatically when linking non-PIC code. This option requests the new PLT and GOT layout. A warning will be given if some object file requires the old style BSS PLT. `--sdata-got' The new secure PLT and GOT are placed differently relative to other sections compared to older BSS PLT and GOT placement. The location of `.plt' must change because the new secure PLT is an initialized section while the old PLT is uninitialized. The reason for the `.got' change is more subtle: The new placement allows `.got' to be read-only in applications linked with `-z relro -z now'. However, this placement means that `.sdata' cannot always be used in shared libraries, because the PowerPC ABI accesses `.sdata' in shared libraries from the GOT pointer. `--sdata-got' forces the old GOT placement. PowerPC GCC doesn't use `.sdata' in shared libraries, so this option is really only useful for other compilers that may do so. `--emit-stub-syms' This option causes `ld' to label linker stubs with a local symbol that encodes the stub type and destination. `--no-tls-optimize' PowerPC `ld' normally performs some optimization of code sequences used to access Thread-Local Storage. Use this option to disable the optimization.  File: ld.info, Node: PowerPC64 ELF64, Next: SPU ELF, Prev: PowerPC ELF32, Up: Machine Dependent 4.10 `ld' and PowerPC64 64-bit ELF Support ========================================== `--stub-group-size' Long branch stubs, PLT call stubs and TOC adjusting stubs are placed by `ld' in stub sections located between groups of input sections. `--stub-group-size' specifies the maximum size of a group of input sections handled by one stub section. Since branch offsets are signed, a stub section may serve two groups of input sections, one group before the stub section, and one group after it. However, when using conditional branches that require stubs, it may be better (for branch prediction) that stub sections only serve one group of input sections. A negative value for `N' chooses this scheme, ensuring that branches to stubs always use a negative offset. Two special values of `N' are recognized, `1' and `-1'. These both instruct `ld' to automatically size input section groups for the branch types detected, with the same behaviour regarding stub placement as other positive or negative values of `N' respectively. Note that `--stub-group-size' does not split input sections. A single input section larger than the group size specified will of course create a larger group (of one section). If input sections are too large, it may not be possible for a branch to reach its stub. `--emit-stub-syms' This option causes `ld' to label linker stubs with a local symbol that encodes the stub type and destination. `--dotsyms, --no-dotsyms' These two options control how `ld' interprets version patterns in a version script. Older PowerPC64 compilers emitted both a function descriptor symbol with the same name as the function, and a code entry symbol with the name prefixed by a dot (`.'). To properly version a function `foo', the version script thus needs to control both `foo' and `.foo'. The option `--dotsyms', on by default, automatically adds the required dot-prefixed patterns. Use `--no-dotsyms' to disable this feature. `--no-tls-optimize' PowerPC64 `ld' normally performs some optimization of code sequences used to access Thread-Local Storage. Use this option to disable the optimization. `--no-opd-optimize' PowerPC64 `ld' normally removes `.opd' section entries corresponding to deleted link-once functions, or functions removed by the action of `--gc-sections' or linker script `/DISCARD/'. Use this option to disable `.opd' optimization. `--non-overlapping-opd' Some PowerPC64 compilers have an option to generate compressed `.opd' entries spaced 16 bytes apart, overlapping the third word, the static chain pointer (unused in C) with the first word of the next entry. This option expands such entries to the full 24 bytes. `--no-toc-optimize' PowerPC64 `ld' normally removes unused `.toc' section entries. Such entries are detected by examining relocations that reference the TOC in code sections. A reloc in a deleted code section marks a TOC word as unneeded, while a reloc in a kept code section marks a TOC word as needed. Since the TOC may reference itself, TOC relocs are also examined. TOC words marked as both needed and unneeded will of course be kept. TOC words without any referencing reloc are assumed to be part of a multi-word entry, and are kept or discarded as per the nearest marked preceding word. This works reliably for compiler generated code, but may be incorrect if assembly code is used to insert TOC entries. Use this option to disable the optimization. `--no-multi-toc' By default, PowerPC64 GCC generates code for a TOC model where TOC entries are accessed with a 16-bit offset from r2. This limits the total TOC size to 64K. PowerPC64 `ld' extends this limit by grouping code sections such that each group uses less than 64K for its TOC entries, then inserts r2 adjusting stubs between inter-group calls. `ld' does not split apart input sections, so cannot help if a single input file has a `.toc' section that exceeds 64K, most likely from linking multiple files with `ld -r'. Use this option to turn off this feature.  File: ld.info, Node: SPU ELF, Next: TI COFF, Prev: PowerPC64 ELF64, Up: Machine Dependent 4.11 `ld' and SPU ELF Support ============================= `--plugin' This option marks an executable as a PIC plugin module. `--no-overlays' Normally, `ld' recognizes calls to functions within overlay regions, and redirects such calls to an overlay manager via a stub. `ld' also provides a built-in overlay manager. This option turns off all this special overlay handling. `--emit-stub-syms' This option causes `ld' to label overlay stubs with a local symbol that encodes the stub type and destination. `--extra-overlay-stubs' This option causes `ld' to add overlay call stubs on all function calls out of overlay regions. Normally stubs are not added on calls to non-overlay regions. `--local-store=lo:hi' `ld' usually checks that a final executable for SPU fits in the address range 0 to 256k. This option may be used to change the range. Disable the check entirely with `--local-store=0:0'. `--stack-analysis' SPU local store space is limited. Over-allocation of stack space unnecessarily limits space available for code and data, while under-allocation results in runtime failures. If given this option, `ld' will provide an estimate of maximum stack usage. `ld' does this by examining symbols in code sections to determine the extents of functions, and looking at function prologues for stack adjusting instructions. A call-graph is created by looking for relocations on branch instructions. The graph is then searched for the maximum stack usage path. Note that this analysis does not find calls made via function pointers, and does not handle recursion and other cycles in the call graph. Stack usage may be under-estimated if your code makes such calls. Also, stack usage for dynamic allocation, e.g. alloca, will not be detected. If a link map is requested, detailed information about each function's stack usage and calls will be given. `--emit-stack-syms' This option, if given along with `--stack-analysis' will result in `ld' emitting stack sizing symbols for each function. These take the form `__stack_' for global functions, and `__stack__' for static functions. `' is the section id in hex. The value of such symbols is the stack requirement for the corresponding function. The symbol size will be zero, type `STT_NOTYPE', binding `STB_LOCAL', and section `SHN_ABS'.  File: ld.info, Node: TI COFF, Next: WIN32, Prev: SPU ELF, Up: Machine Dependent 4.12 `ld''s Support for Various TI COFF Versions ================================================ The `--format' switch allows selection of one of the various TI COFF versions. The latest of this writing is 2; versions 0 and 1 are also supported. The TI COFF versions also vary in header byte-order format; `ld' will read any version or byte order, but the output header format depends on the default specified by the specific target.  File: ld.info, Node: WIN32, Next: Xtensa, Prev: TI COFF, Up: Machine Dependent 4.13 `ld' and WIN32 (cygwin/mingw) ================================== This section describes some of the win32 specific `ld' issues. See *Note Command Line Options: Options. for detailed description of the command line options mentioned here. _import libraries_ The standard Windows linker creates and uses so-called import libraries, which contains information for linking to dll's. They are regular static archives and are handled as any other static archive. The cygwin and mingw ports of `ld' have specific support for creating such libraries provided with the `--out-implib' command line option. _exporting DLL symbols_ The cygwin/mingw `ld' has several ways to export symbols for dll's. _using auto-export functionality_ By default `ld' exports symbols with the auto-export functionality, which is controlled by the following command line option