LD usage -- the last step of the GCC process -- Link

Today, we have understood the usage of LD used by Vivi, And the meanings of common options are also clear. After looking at the link script of the kernel, we found that it was quite complicated, and we had to have a good grasp of the global situation. We must also be clear about the allocation of the entire address space. This cannot be done for the time being. It is a follow-up job. First, let's summarize the basic usage of LD. Because linkers and loaders has not been read, we cannot summarize it yet. However, you have a deeper understanding of links and loads. When reading using lD, many places naturally understand it. Gradually straighten out this knowledge and experience association.

1. What is lD? What does it do? LD is one of the GNU binutils tool sets and one of the many linkers. The completed function is naturally the basic function of the linker: link various target files and library files, redirect their data, and complete symbol parsing. Linking mainly involves four aspects: storage allocation, symbol management, libraries, and relocation. LD can identify a linker scriopt file in linker command language to explicitly control the link process. Using the BFD (binary format description) library, LD can read and operate target files in various formats, such as coff (Common Object File Format), ELF (executable and linking format), and A. Out. 2. Common options-B Target: Set the file format of the target file-e address: Set the start address of the target file-EB: the target file of the big-Endian-El link small-Endian. file-l libname, -ltest) -l Directory: Path of the file to be searched when searching for the library file to be linked-o file: Set the name of the output file-s remove all Symbol Information in the output file-s remove debugging Symbol Information in the output file -T file: Read the link description script, to determine the location address of symbols, such as-V output LD version information-x remove all local symbol information-x remove temporary local symbol information, by default, this option-the output file link created by bstatic is set to the static Link Library-the output file link created by bdynamic dynamic link library-tbss address to set the start address of section BSS-tdata address Set the start address of section data-ttext address set the start address of section Text 3. Link Description script link description script describes how each section of each input file maps to each section of the output file, and control the memory layout of sections and symbols in the output file. Each section in the target file has a name and size, and can be identified as loadable (indicating that this section can be loaded into memory) and allocatable (indicating that a space must be opened for this section, but there is no actual content downloaded here ). If it is not loadable or allocatable, debugging information is generally contained. Each output Section identified by loadable or allocatable has two types of addresses: VMA (virtual memory address), which is the running address of the section when the output file is running; one is LMA (load memory address), which is the loading address of the section when the output file is loaded. Generally, the two addresses are the same. However, in embedded systems, the execution address and loading address are often inconsistent. For example, load the output file to the flash memory of the Development Board (the address is specified by LMA), but during running, copy the output file from the flash memory to the SDRAM for running (the address is specified by VMA ). Use comments in the Link script and "/*... */". Each target file has many symbols. Each symbol has a name and an address. A symbol can be defined or undefined. A special identifier is required for common symbols, because in the target file, common symbols do not have a specific input section. The linker processes common symbols as if they are all in a section called common. The following describes the content and analysis of the LD script of Vivi. (1) [makefile]

LINKFLAGS = -Tarch/vivi.lds -Bstatic

It can be seen that the link script is arch/Vivi. LDS, And the link is static library. But under arch, there is no Vivi. LDS, But Vivi. LDS. In. After reading the content of vivi. LDS. In,

SECTIONS {   . = TEXTADDR;   .text : { *(.text) }   .data ALIGN(4) : { *(.data) }   .bss ALIGN(4) : { *(.bss) *(COMMON) } }

Obviously, this is the original Vivi link script. However, there is a variable textaddr with no value assigned. That is to say, this quantity varies according to the configuration, so the generation method must be executed in makefile. For the next step, see [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) arch/vivi.lds arch/vivi.lds: $(LDSCRIPT)         @sed s/TEXTADDR/$(TEXTADDR)/ $(LDSCRIPT) >$@

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

SECTIONS {   . = 0x33f00000;   .text : { *(.text) }   .data ALIGN(4) : { *(.data) }   .bss ALIGN(4) : { *(.bss) *(COMMON) } }

Segments. The first line indicates that the current address is 0x33f00000, Which is VMA and the starting address of the text segment. The second line uses the wildcard * to indicate all characters. This means that the content of the text section of each target file is put in the same. Text. The third line indicates that the content of the data section of each specified target file is put in the same. data, and the four-byte boundary alignment is required. The fourth line indicates that the content of the BSS section of each specified target file is put in the same. BSS, and all common symbols are put in the common, and the boundary alignment of four bytes is required.

This is the simplest LD scripts, but it is enough. If you do not consider alignment and other factors, you can directly specify-ttext 0x33f00000 in the command line to complete the process. Of course, for Linux kernel and so on, LD scripts should handle complicated memory allocation and other operations, which should be more complicated. Read the using LD manual by referring to those methods, at the same time, we also need to study the memory allocation of MCU so as to make reasonable arrangements.