"Go" link script (1)

1. What is LD? What role does it have?

LD is one of the GNU Binutils toolset, which is a large number of linkers (linker). The complete function is naturally the basic function of the linker: Linking various object files and library files, redirecting their data, and completing the symbolic parsing. Linking in fact, the main task is to complete four aspects of the work: storage allocation, symbol management, libraries, relocation. LD can identify a linker command language linker scriopt file to explicitly control the linking process. With BFD (Binary format Description) library, LD can read and manipulate COFF (Common Object file format), ELF (executable and linking format), A.out the target file in various formats. 2. Common Options -B Target sets the file format of the destination file-e address sets the start of the destination file-eb link Big-endian target file-el link Small-endian target file- l LIBNAME The library file to be linked when the program is created (for example, if a library is test, it can be-ltest)-L DIRECTORY search for file paths when searching for library files to link-o file sets the name of the output files-S removes all symbol information from the output file-S removes debug symbol information from the output file-T FILE reads the link description script to determine the location address of the symbol, etc.-V Output LD version information-X Removes all local symbolic information- x removes temporary local symbol information, which is set by default-bstatic Create an output file link to a static link library-bdynamic Create an output file link dynamic link library-TBSS Address to set the start of section BSS-tdata Address Setting the start of section data-ttext Address Set the start of section text3. Link Description ScriptThe Link Description script Describes how each section of each input file maps to sections in the output file and controls the memory layout of the section and symbol in the output file. each section in the destination file has a name and size and can be identified as loadable (indicating that the section can be loaded into memory), allocatable (indicating that a space must be opened for the section, but no actual content is downloaded here). If it is not loadable or allocatable, debugging information is generally included.

Each output section with a loadable or allocatable identity has two addresses, one of which is the VMA address, which is the run-time section of the output file runtime, and the LMA (Load Memory address), which is the load address of the section when the output file is loaded. Generally, the two addresses are the same. But in the embedded system, the execution address and the load address inconsistency often exist. If the output file is loaded into the flash memory of the Development Board (the address is specified by the LMA), but at runtime, the output file in Flash memory is copied to the SDRAM (the address is specified by VMA).
To use annotations in a link script, you can use "/*...*/".

Each target file has a number of symbols, each with a name and an address, a symbol can be defined, or it can be undefined. For normal symbols, a special identifier is required because the normal symbol does not have a specific input section in the target file. The linker handles ordinary symbols as if they were in a section called Common.

The contents and analysis of the LD script of Vivi are given below.

(1) [Makefile]

LINKFLAGS= -Tarch/vivi.lds-Bstatic

As can be seen, the linked script is arch/vivi.lds and links to the static library. But there is no vivi.lds in arch, but there is vivi.lds.in. Looking at the contents of the vivi.lds.in,

SECTIONS{ .= Textaddr; . text:{*(. text) }   .data align< Span style= "COLOR: #00cc" > (4) : { * (.data ) "   .BSS align (4 ) : {* (.bss * (Common) } "

Obviously, this is the original Vivi link script. However, there is a variable textaddr is not assigned, that is, this amount is different depending on the configuration, so the generation method must be executed in makefile. The next step depends on [Arch/makefile]

(2) [Arch/makefile]

LDSCRIPT= arch/vivi.lds.in

ifeq ($ (config_arch_s3c2410 ) ,y) Machine = s3c2410   ifeq ($ (Config_s3c2410_nand_boot) ,y"     textaddr = 0x33f00000   else     textaddr = 0x00000000    endif endif

 

vivi: $ (Head/ Vivi.lds Arch/vivi.lds : $ (Ldscript           @sed s/textaddr/$ (Textaddr/$ (Ldscript >$@

Obviously, the main task of this step is to replace the textaddr in the vivi.lds.in file with the actual value of the configuration. According to my configuration, my textaddr here is 0x33f00000.

SECTIONS{ .= 0x33f00000; . text:{*(. text) }   .data align< Span style= "COLOR: #00cc" > (4) : { * (.data ) "   .BSS align (4 ) : {* (.bss * (Common) } "

Sections represents a segment. The first line indicates that the current address is 0x33f00000, which is VMA, and is also the starting address of the text segment. The second line uses the wildcard character * to denote all characters, meaning that the contents of the text section of each target file specified are placed in the same. Text. The third line indicates that the contents of the data section of each specified target file are placed in the same. Data and are aligned to a four-byte boundary. Row four indicates that the contents of the BSS section of each specified target file are placed in the same. BSS, all normal symbols are placed in the common, and four-byte boundaries are aligned.

It's the simplest LD scripts, but it's enough. If you do not consider factors such as alignment, you can do so by specifying-ttext 0x33f00000 directly on the command line. Of course, for Linux kernel, and so on, LD scripts to handle complex memory allocation and other operations, the corresponding is more complicated, read those methods is to consult using LD Manual, but also to study the memory allocation of the MCU, so as to make reasonable arrangements

"Go" link script (1)