This will define the symbol as a global symbol. The first case will define symbol to the value of expression. In the other cases, symbol must already be defined, and the value will be adjusted accordingly. Expressions are defined below; see section Expressions in Linker Scripts. The section of the symbol will be set from the section of the expression; for more information, see section The Section of an Expression.
In some cases, it is desirable for a linker script to define a symbol only if it is referenced and is not defined by any object included in the link. This can also make the linker script easier to understand because you can use those commands at meaningful points in the layout of the output file. If you do not use a SECTIONS command in your linker script, the linker will place each input section into an identically named output section in the order that the sections are first encountered in the input files.
If all input sections are present in the first file, for example, the order of sections in the output file will match the order in the first input file. The first section will be at address zero. The whitespace around section is required, so that the section name is unambiguous. The colon and the curly braces are also required.
The line breaks and other white space are optional. The name of the output section is section. In formats which only support a limited number of sections, such as a. If the output format supports any number of sections, but with numbers and not names as is the case for Oasys , the name should be supplied as a quoted numeric string. A section name may consist of any sequence of characters, but a name which contains any unusual characters such as commas must be quoted.
The address is an expression for the VMA the virtual memory address of the output section. If you do not provide address , the linker will set it based on region if present, or otherwise based on the current value of the location counter. If you provide address , the address of the output section will be set to precisely that. If you provide neither address nor region , then the address of the output section will be set to the current value of the location counter aligned to the alignment requirements of the output section.
The alignment requirement of the output section is the strictest alignment of any input section contained within the output section. For example,. The address may be an arbitrary expression; section Expressions in Linker Scripts. For example, if you want to align the section on a 0x10 byte boundary, so that the lowest four bits of the section address are zero, you could do something like this:.
The most common output section command is an input section description. The input section description is the most basic linker script operation. You use output sections to tell the linker how to lay out your program in memory. You use input section descriptions to tell the linker how to map the input files into your memory layout. An input section description consists of a file name optionally followed by a list of section names in parentheses. The file name and the section name may be wildcard patterns, which we describe further below see section Input section wildcard patterns.
The most common input section description is to include all input sections with a particular name in the output section. In the first example, they will be intermingled.
You can specify a file name to include sections from a particular file. You would do this if one or more of your files contain special data that needs to be at a particular location in memory. For example: data. This is not commonly done, but it may by useful on occasion. If you did not, the linker will attempt to open the file as an input file, as though it appeared on the command line. Note that this differs from an INPUT command, because the linker will not search for the file in the archive search path.
In an input section description, either the file name or the section name or both may be wildcard patterns. File name wildcard patterns only match files which are explicitly specified on the command line or in an INPUT command. The linker does not search directories to expand wildcards. If a file name matches more than one wildcard pattern, or if a file name appears explicitly and is also matched by a wildcard pattern, the linker will use the first match in the linker script.
You can change this by using the SORT keyword, which appears before a wildcard pattern in parentheses e. When the SORT keyword is used, the linker will sort the files or sections into ascending order by name before placing them in the output file.
The map file shows precisely how input sections are mapped to output sections. This example shows how wildcard patterns might be used to partition files. You can use this to place common symbols from a particular input file in one section while common symbols from other input files are placed in another section.
For example:. In this case, the linker will use a different special section name for other types of common symbols. This permits you to map the different types of common symbols into memory at different locations.
This notation is now considered obsolete. The following example is a complete linker script. Each keyword is followed by an expression in parentheses providing the value to store see section Expressions in Linker Scripts.
The value of the expression is stored at the current value of the location counter. After storing the bytes, the location counter is incremented by the number of bytes stored. When both host and target are 32 bits, an expression is computed as 32 bits. If the object file format of the output file has an explicit endianness, which is the normal case, the value will be stored in that endianness. When the object file format does not have an explicit endianness, as is true of, for example, S-records, the value will be stored in the endianness of the first input object file.
You may use the FILL command to set the fill pattern for the current section. It is followed by an expression in parentheses. Any otherwise unspecified regions of memory within the section for example, gaps left due to the required alignment of input sections are filled with the two least significant bytes of the expression, repeated as necessary.
A FILL statement covers memory locations after the point at which it occurs in the section definition; by including more than one FILL statement, you can have different fill patterns in different parts of an output section.
The object file produced by incremental linking is smaller than a static library produced from the same object files. At link time the result of incremental linking also loads faster than a static library assuming that the majority of objects in the library are used. When multiple object files are linked together the resulting code is better optimized than with link-time optimizations disabled for example, cross-module inlining happens , but most of benefits of whole program optimizations are lost.
During the incremental link by -r the linker plugin defaults to rel. To maintain whole program optimization, it is recommended to link such objects into static library instead. Alternatively it is possible to use H. Search the library named library when linking. The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended. The -l option is passed directly to the linker by GCC. Refer to your linker documentation for exact details. The general description below applies to the GNU linker.
The linker searches a standard list of directories for the library. The directories searched include several standard system directories plus any that you specify with -L. Static libraries are archives of object files, and have file names like lib library. Some targets also support shared libraries, which typically have names like lib library.
If both static and shared libraries are found, the linker gives preference to linking with the shared library unless the -static option is used. It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified.
If bar. Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib , -nolibc , or -nodefaultlibs is used. Do not use the standard system libraries when linking. Only the libraries you specify are passed to the linker, and options specifying linkage of the system libraries, such as -static-libgcc or -shared-libgcc , are ignored.
The standard startup files are used normally, unless -nostartfiles is used. The compiler may generate calls to memcmp , memset , memcpy and memmove. These entries are usually resolved by entries in libc.
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. This can be done by putting something like:. The second GNU extension is to allow multiple versions of the same function to appear in a given shared library. In this way an incompatible change to an interface can take place without increasing the major version number of the shared library, while still allowing applications linked against the old interface to continue to function.
An example of this would be:. 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. Only one version of a symbol can be declared '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.
The command language includes a number of other commands that you can use for specialized purposes. They are similar in purpose to command-line options. Machines where ld has no additional functionality are not listed. 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.
The linker accesses object and archive files using the BFD libraries. These libraries allow the linker to use the same routines to operate on object files whatever the object file format.
A different object file format can be supported simply by creating a new BFD back end and adding it to the library. To conserve runtime memory, however, the linker and associated tools are usually configured to support only a subset of the object file formats available.
As with most implementations, BFD is a compromise between several conflicting requirements. The major factor influencing BFD design was efficiency: any time used converting between formats is time which would not have been spent had BFD not been involved.
This is partly offset by abstraction payback; since BFD simplifies applications and back ends, more time and care may be spent optimizing algorithms for a greater speed. One minor artifact of the BFD solution which you should bear in mind is the potential for information loss. There are two places where useful information can be lost using the BFD mechanism: during conversion and during output. See section Information Loss. When an object file is opened, BFD subroutines automatically determine the format of the input object file.
They then build a descriptor in memory with pointers to routines that will be used to access elements of the object file's data structures. As different information from the the object files is required, BFD reads from different sections of the file and processes them.
For example, a very common operation for the linker is processing symbol tables. Each BFD back end provides a routine for converting between the object file's representation of symbols and an internal canonical format. When the linker asks for the symbol table of an object file, it calls through a memory pointer to the routine from the relevant BFD back end which reads and converts the table into a canonical form.
The linker then operates upon the canonical form. When the link is finished and the linker writes the output file's symbol table, another BFD back end routine is called to take the newly created symbol table and convert it into the chosen output format. Information can be lost during output. The output formats supported by BFD do not provide identical facilities, and information which can be described in one form has nowhere to go in another format.
One example of this is alignment information in b. There is nowhere in an a. The linker will still use the alignment information internally, so the link is performed correctly. Another example is COFF section names. COFF files may contain an unlimited number of sections, each one with a textual section name. If the target of the link is a format which does not have many sections e. You can circumvent this problem by describing the desired input-to-output section mapping with the linker command language.
Information can be lost during canonicalization. The BFD internal canonical form of the external formats is not exhaustive; there are structures in input formats for which there is no direct representation internally. This means that the BFD back ends cannot maintain all possible data richness through the transformation between external to internal and back to external formats.
This limitation is only a problem when an application reads one format and writes another. Each BFD back end is responsible for maintaining as much data as possible, and the internal BFD canonical form has structures which are opaque to the BFD core, and exported only to the back ends.
When a file is read in one format, the canonical form is generated for BFD and the application. At the same time, the back end saves away any information which may otherwise be lost. If the data is then written back in the same format, the back end routine will be able to use the canonical form provided by the BFD core as well as the information it prepared earlier. Since there is a great deal of commonality between back ends, there is no information lost when linking or copying big endian COFF to little endian COFF, or a.
When a mixture of formats is linked, the information is only lost from the files whose format differs from the destination. The greatest potential for loss of information occurs when there is the least overlap between the information provided by the source format, that stored by the canonical format, and that needed by the destination format.
A brief description of the canonical form may help you understand which kinds of data you can count on preserving across conversions. Reporting a bug may help you by bringing a solution to your problem, or it may not. But in any case the principal function of a bug report is to help the entire community by making the next version of ld work better. Bug reports are your contribution to the maintenance of ld. In order for a bug report to serve its purpose, you must include the information that enables us to fix the bug.
A number of companies and individuals offer support for GNU products. If you obtained ld from a support organization, we recommend you contact that organization first.
The fundamental principle of reporting bugs usefully is this: report all the facts. If you are not sure whether to state a fact or leave it out, state it! Often people omit facts because they think they know what causes the problem and assume that some details do not matter. Thus, you might assume that the name of a symbol you use in an example does not matter.
Well, probably it does not, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that name is stored in memory; perhaps, if the name were different, the contents of that location would fool the linker into doing the right thing despite the bug. This becomes relevant when garbage collection is performed at link time, enabled by passing the --gc-sections switch to the linker. The KEEP statement instructs the linker to use the specified section as a root node when creating a dependency graph, looking for unused sections.
Essentially forcing the section to be marked as used. This statement is commonly seen in linker scripts targeting the ARM architecture for placing the interrupt vector table at offset 0x Without this directive the table, which might not be referenced explicitly in code, would be pruned out.
It is possible to define arbitrary symbols within a linker script. These symbols are added into the program's symbol table. Each symbol in the table has a name and an associated address. Symbols within a linker script that have been assigned a value will be given external linkage, and are accessible within the program's code as pointers. An example script showing three different places that symbol assignment may be used can be seen below:.
Jump to: navigation , search. Category : Linkers.
0コメント