ARM Architecture C Language Addressing analysis--an exploration from U-boot relocation (II.) __u-boot

ARM Architecture C Language addressing resolution--
Exploration from the U-boot relocation (II.) by LazycatdesignWww.lazycatdesign.com

The analysis of ARM architecture C-language pic addressing mode
As mentioned in the preceding article, can you produce a code that runs in any address section? Yes, it's called Position-independent Code, or PIC (Windows Dll,linux Share Object, both of which are typical pic files). So how to produce pic? Can be generated by specifying compilation options for the compiler, such as:
Arm-none-eabi-gcc-c-o-fpic MAIN.O main.c
Another example:
Arm-none-eabi-gcc-c-o-fpie MAIN.O main.c
The target file generated by this compilation contains the information required by PIC,-fpic,-fpie is the PIC compilation option for GCC. LD also has PIC connection option-pie, to obtain a complete pic executable file, you must specify the-pie option for LD when connecting to the target file, for example:
Arm-none-eabi-ld-tarm_pic.lds Main.o-o Arm_pic-pie

One of the most important features of the PIC executable file is that it contains a global Offset Table, referred to as got. Each got entry records the address of an object (the object can be a global variable or function), and the CPU reads got entry from the got to obtain the address of the global variable.

The following discussion specifies how the code generated by the-FPIC compilation option and the-pie connection option is addressed.
command line into the Arm_pic directory, make Gcc_pic=-fpic Ld_pic=-pie, get the following file: Arm_pic (elf format file)

Arm_pic.bin (binary Mirror file) arm_pic.dump (disassembly file) arm_pic.map (Memory map file)

Visible from the Arm_pic.dump, there is a. Got data segment, this got contains 6 entry, and the base address is 0x402001d0,6 entry to indicate the addresses of 6 global variables.

Next through the main function to analyze pic addressing, the main disassembly code is shown in the following illustration:

Unlike the assembly code that was analyzed in the previous article, lable is now stored in an offset, not an address value. The GLOBAL_VAR1 addressing is done in the following 3 steps (as is the Global_str addressing method): R3 obtains the address of got base relative to the PC by Lable1, thereby determining the location of the site; got obtains R2 through Lable2 VAR1 GTO Entry The address of R3 GTO GLOBAL_VAR1 to obtain entry address, compared with offset of got base, R2 + global_var1 additive (Base + offset);

The address of each variable is ultimately obtained from the got, this is the way pic is addressed, and its core, to get got base address, you can modify the address of the variable to relocation (reposition).

OK, as discussed in the previous article, we put arm_pic whole copy to 0x80000000, and add the offset of each entry in got to 0x3fe00000, So that all C global variables address are adjusted to the new address (this operation to modify the variable address is called relocation), the main function and the Foo function in the variable addressing will not be wrong, then the program will be able to run correctly. Not yet, why. Got save only the variable address and function address of C, but don't forget, our project is not only C code, but also assembly code. So how does the assembly code object relocation? How do we get the object information that needs to be relocation in the assembly code? The answer is in the. Rel.dyn data segment and the. Dynsym data segment, which will be analyzed in the next article, as well as the specific analysis of how u-boot2011.12 relocation.