HongMeng kernel source code analysis (relocation) | in line with international standards, a spokesman for the external OpenHarmony source | | best blog analysis v55.02

Zi Zhang asked about the way to be a good man. The Master said, “He does not use his traces, nor does he enter his chambers.” The Analects of Confucius: Advanced chapter

A hundred blog series. This is:

V55. Xx HongMeng kernel source code analysis (relocation) | in line with international standards, a spokesman for the external

Loading and running related articles are:

• V51. Xx HongMeng kernel source code analysis (ELF format) | application is not the main entrance
• V53. Xx HongMeng kernel source code analysis (ELF) | do you want to forget her elder sister both of you are not silver
• V54. Xx HongMeng kernel source code analysis (static linking) | complete small projects through the static linking process
• V55. Xx HongMeng kernel source code analysis (relocation) | in line with international standards, a spokesman for the external
• V56. Xx HongMeng kernel source code analysis (process image) | how ELF loaded running?

A program from the source to be executed, which goes through three processes:

• Compile: To compile a.c file into a.o file, regardless of the connection between the.o files.
• Static linking: Combines all.o files into one. So or. Out file, handling the layout of all.o file sections in the target file.
• Dynamic linking: loads a. So or A.out file into memory and handles the layout of the loaded file in memory.

What is relocation

Relocation is the process of converting a program’s logical address space into an actual physical address space in memory. It is the basis of realizing multiple programs running simultaneously in memory. There are two kinds of relocation, namely dynamic relocation and static relocation.

• 1. Static relocation: it is completed in the process of loading the program into memory. It means that before the program starts to run, all the items related to the address in the program have been relocated. That is, the static location of the address has been completed when the executable/shared object file is generated, which solves the internal contradiction of the executable/shared object file.
• 2. Dynamic relocation: it is not completed when the program is loaded into memory, but the CPU each memory access by the dynamic address conversion mechanism (hardware) automatically convert the relative address into absolute address. Dynamic relocation requires software and hardware cooperation. In other words, the external contradiction of executable file/shared object file needs to be solved by the external environment, which provides a diplomatic explanation to the external world. This is the last part of this article.

Ten types of relocation

• There are 10 types of relocation, which you can check in practice. Some of these types can be seen in this section, as follows:

Interpretation of the

• FPIC stands for Position Independent Code, which is used to generate position-independent Code.

Objdump command

The objdump command is a Linux disassembly of object files or executables in a readable format that gives you more insight into the additional information that binaries may carry. This article will use it to explain the implementation details of static relocation and the preparation of dynamic relocation preconditions. Run the objdump command as a whole

root@5e3abe332c5a:/home/docker/test4harmony/54# objdump Usage: objdump <option(s)> <file(s)> Display information from object <file(s)>. At least one of the following switches must be given: -a, --archive-headers Display archive header information -f, --file-headers Display the contents of the overall file header -p --private-headers Display object format Specific file header contents -p, --private=OPT, OPT... Display object format specific contents -h, --[section-]headers Display the contents of the section headers, --all-headers Display the contents of all headers -d, -- Disassemble Display assembler contents of executable sections -d,  --disassemble-all Display assembler contents of all sections --disassemble=<sym> Display assembler contents from <sym> -s, --source Intermix source code with disassembly --source-comment[=< TXT >] Prefix lines of source code with < TXT > -s, --full contents Display the full contents of all sections requested-g, -- Debugging Display debug information in object file-e, --debugging-tags Display debug information using ctags style -g, --stabs Display (in raw form) any stabs info in the file-w [lLiaprmfFsoRtUuTgAckK] or --dwarf[=rawline, =decodedline, =info, =abbrev, =pubnames, =aranges, =macro, =frames, =frames-interp, = STR, =loc, =Ranges, =pubtypes, =gdb_index, =trace_info, Trace_abbrev, =trace_aranges, =addr, =cu_index, =links, =follow-links] Display DWARF info in the file -- CTF =SECTION Display CTF info from SECTION -t, --syms Display the contents of the symbol table(s) -t, --dynamic-syms Display the contents of the dynamic symbol table -r, -- Reloc Display the relocation entries in the file-r, --dynamic-reloc Display the dynamic relocation entries in the file @<file> Read options from <file> -v, --version Display this program's version number -i, --info List object formats and architectures supported -H,  --help Display this informationCopy the code

objdump -S ./obj/main.o

Main. o is a relocatable file, known from readelf

root@5e3abe332c5a:/home/docker/test4harmony/54# readelf -h ./obj/main.o ELF Header: Magic: 7f 45 4C 46 02 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's Complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0Copy the code

root@5e3abe332c5a:/home/docker/test4harmony/54# objdump -S ./obj/main.o ./obj/main.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <main>: #include <stdio.h> #include "part.h" extern int g_int; extern char *g_str; Int main() {0: f3 0f 1e fa endbr64 4: 55 push % RBP 5: 48 89 e5 mov % RSP, % RBP 8: 48 48 ec 10 sub $0x10, % RSP int loc_int = 53; C: c7 45 f4 35 00 00 00 movl $0x35, -0xc(% RBP) char *loc_str = "harmony OS "; 13: 48 8d 05 00 00 00 00 00 LEA 0x0(%rip), %rax # 1a <main+ 0x1A > 1a: 48 89 45 f8 mov %rax, -0x8(% RBP) printf("main start - g_int = %d, g_str = %s.\n", g_int, g_str); 1e: 48 8b 15 00 00 00 00 mov 0x0(%rip), % RDX # 25 <main+0x25> 25: 8b 05 00 00 00 00 mov 0x0(%rip), %eax # 2b <main+0x2b> 2b: 8b 05 00 00 00 00 00 mov 0x0(%rip), %eax # 2b <main+0x2b> 2b: 89c6 mov %eax, %esi 2d: 48 8d 3d 00 00 00 00 LEA 0x0(%rip), %rdi # 34 <main+0x34> 34: b8 00 00 00 00 00 mov $0x0, %eax 39: e8 00 00 00 00 callq 3e <main+0x3e> func_int(loc_int); 3e: 8b 45 f4 mov -0xc(% RBP), % eAX 41:89 c7 mov %eax, %edi 43: e8 00 00 00 00 00 callq 48 <main+0x48> func_str(loc_str); 48: 48 8b 45 f8 mov -0x8(% RBP), %rax 4c: 48 89 c7 mov %rax, %rdi 4f: E8 00 00 00 00 callq 54 <main+0x54> printf(" end of main - global g_int = %d, global g_str = %s.\n", g_int, g_str); 55:48 8b 15 00 00 00 00 mov 0x0(%rip), % RDX # 5b <main+0x5b> 5b: 8b 05 00 00 00 00 mov 0x0(%rip), %eax # 61 <main+0x61> 61:89 c6 mov %eax, %esi 63: 48 8d 3d 00 00 00 00 LEA 0x0(%rip), %rdi # 6a <main+0x6a> 6A: B8 00 00 00 00 MOV $0x0, %eax 6f: e8 00 00 00 00 callq 74 <main+0x74> return 0; 74: b8 00 00 00 00 mov $0x0, %eax 79: c9 leaveq 7a: C3 retqCopy the code

Interpretation of the

• Pay attention to those00 00 00 00These are things that the compiler cannot determine for the time being. So let’s do this visuallyOFFSETTo offset0x16.0x21, that is, the contents of the following table

objdump -r ./obj/main.o

root@5e3abe332c5a:/home/docker/test4harmony/54# objdump -r ./obj/main.o
./obj/main.o:     file format elf64-x86-64
RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE
0000000000000016 R_X86_64_PC32     .rodata-0x0000000000000004
0000000000000021 R_X86_64_PC32     g_str-0x0000000000000004
0000000000000027 R_X86_64_PC32     g_int-0x0000000000000004
0000000000000030 R_X86_64_PC32     .rodata+0x000000000000000c
000000000000003a R_X86_64_PLT32    printf-0x0000000000000004
0000000000000044 R_X86_64_PLT32    func_int-0x0000000000000004
0000000000000050 R_X86_64_PLT32    func_str-0x0000000000000004
0000000000000057 R_X86_64_PC32     g_str-0x0000000000000004
000000000000005d R_X86_64_PC32     g_int-0x0000000000000004
0000000000000066 R_X86_64_PC32     .rodata+0x0000000000000044
0000000000000070 R_X86_64_PLT32    printf-0x0000000000000004
Copy the code

Interpretation of the

• The values 0x16 and 0x21 are 0, which means they are set to null (0x000000) for addresses that the compiler cannot determine, and the compiler generates a one-to-one record that tells the linker to correct the memory address of the function in the instruction when linking, and tells it what relocation type it is. Where to find data to fill.

• External global variables relocate g_str, g_int

  0000000000000021 R_X86_64_PC32 g_str-0x0000000000000004 0000000000000027 R_X86_64_PC32 g_int-0x0000000000000004 --- 1e: 48 8b 15 00 00 00 00 mov 0x0(%rip), % RDX # 25 <main+0x25> 25: 8B 05 00 00 00 00 00 00 mov 0x0(%rip), %eax # 2b <main+0x2b>Copy the code

  The compiler does not even know which.o file g_str is in, and certainly does not know the runtime address of g_str, so setting up A relocation in the g.o file requires subsequent procedures to modify the value at offset 0x21 in the main.o mirror according to “S(g_str memory address) -a (0x04)”.

• Function relocation, relocation type is R_X86_64_PLT32

  000000000000003a R_X86_64_PLT32    printf-0x0000000000000004
  0000000000000044 R_X86_64_PLT32    func_int-0x0000000000000004
  0000000000000050 R_X86_64_PLT32    func_str-0x0000000000000004
  0000000000000070 R_X86_64_PLT32    printf-0x0000000000000004
  ---
  39:   e8 00 00 00 00          callq  3e <main+0x3e>
  43:   e8 00 00 00 00          callq  48 <main+0x48>
  Copy the code

  Similarly, the compiler does not even know which.o file ‘ ‘func_int’ and printf ‘are in, and certainly does not know their runtime addresses, so it sets a relocation in main.o that will later change the value at the 3a offset in the main.o image.

• The other data provided by Ben.o is as follows

objdump -sj .rodata ./obj/main.o

root@5e3abe332c5a:/home/docker/test4harmony/54# objdump -sj .rodata ./obj/main.o ./obj/main.o: file format elf64-x86-64 Contents of section .rodata: 0000 6861726d 6f6e7920 6f730000 00000000 harmony os...... 0010 6d61696e 20e5bc80 e5a78b20 2d20e585 main ...... -.. 0020 a8e5b180 20675f69 6e74203d 2025642c .... G_int = %d, 0030 20e585a8 e5b18020 675f7374 72203D20...... g_str = 0040 25732e0a 00000000 6d61696e 20e7bb93 %s...... main ... 0050 e69d9f20 2d20e585 a8e5b180 20675f69 ... -... G_i 0060 6e74203D 2025642c 20e585a8 e5b18020nt = %d,...... 0070 675f7374 72203d20 25732e0a 00 g_str = %s...Copy the code

Interpretation of the

• Internal variable relocation.

  13:   48 8d 05 00 00 00 00    lea    0x0(%rip)，%rax        # 1a <main+0x1a>
  ---
  0000000000000016 R_X86_64_PC32     .rodata-0x0000000000000004
  Copy the code

  Because it is a local variable, the compiler knows that the data is placed.rodataTo change the value of offset 0x16 in main.o image according to “S(memory address of main.o mirror. Rodata) -a (0x04)”.

Reanalyze the statically linked executable

objdump -S ./bin/weharmony

root@5e3abe332c5a:/home/docker/test4harmony/54# objdump -S ./bin/weharmony Disassembly of section .text: 0000000000001188 <func_str>: void func_str(char *str) { 1188: f3 0f 1e fa endbr64 118c: 55 push %rbp 118d: 48 89 e5 mov % RSP, % RBP 1190: 48 83 ec 10 sub $0x10, % RSP 1194: 48 89 7d f8 mov %rdi, -0x8(% RBP) g_str = STR; 1195:48 8b 45 f8 mov -0x8(% RBP), %rax 119c: 48 89 05 75 2e 00 00 mov %rax, 0x2e75(%rip) # 4018 <g_str> printf("func_str g_str = %s.\n", g_str); 11a3: 48 8b 05 6e 2e 00 00 mov 0x2e6e(%rip), %rax # 4018 <g_str> 11aa: 48 89 c6 mov %rax, %rsi 11ad: 48 8D 3d 83 0E 00 00 LEA 0xe83(%rip), % Rdi # 2037 <_IO_stdin_used+0x37> 11b4: b8 00 00 00 00 MOV $0x0, %eax 11b9: e8 92 fe ff ff callq 1050 <printf@plt> 11be: 90 nop 11bf: c9 leaveq 11c0: c3 retq 00000000000011c1 <main>: #include <stdio.h> #include "part.h" extern int g_int; extern char *g_str; Int main() {11c1: f3 0f 1e fa endbr64 11c5:55 push % RBP 11c6:48 89 e5 mov % RSP, % RBP 11c9: 48 48 ec 10 sub $0x10, % RSP int loc_int = 53; Movl $0x35, -0xc(% RBP) char *loc_str = "harmony OS "; 11d4:48 8D 05 75 0E 00 00 LEA 0xe75(%rip), % RAx # 2050 <_IO_stdin_used+0x50> 11db: 48 89 45 f8 mov %rax, -0x8(% RBP) printf("main start - g_int = %d, g_str = %s.\n", g_int, g_str); 11df: 48 8b 15 32 2e 00 00 mov 0x2e32(%rip), % RDX # 4018 <g_str> 11e6: 8b 05 24 2e 00 00 mov 0x2e24(%rip), %eax # 4010 <g_int> 11ec: 89c6 mov %eax, %esi 11ee: 8b 05 24 2e 00 00 mov 0x2e24(%rip), %eax # 4010 <g_int> 11ec: 89c6 mov %eax, %esi 11ee: 48 8d 3D 6B 0E 00 00 LEA 0xe6B (%rip), %rdi # 2060 <_IO_stdin_used+0x60> 11f5: b8 00 00 00 00 MOV $0x0, %eax 11fa: e8 51 fe ff ff callq 1050 <printf@plt> func_int(loc_int); 11ff: 8b 45 f4 mov -0xc(% RBP), %eax 1202:89 c7 mov %eax, %edi 1204: e8 40 ff ff ff callq 1149 <func_int> func_str(loc_str); 1209:48 8b 45 f8 mov -0x8(% RBP), %rax 120d: 48 89 c7 mov %rax, %rdi 1210: E8 73 ff ff ff callq 1188 <func_str> printf(" end of main - global g_int = %d, global g_str = %s.\n", g_int, g_str); 1215:48 8b 15 fc 2d 00 00 mov 0x2dfc(%rip), % RDX # 4018 <g_str> 1215:48 8b 15 fc 2d 00 00 00 mov 0x2dfc(%rip), % RDX # 4018 <g_str> 1215:48 8b 8b 05 EE 2d 00 00 mov 0x2dee(%rip), %eax # 4010 <g_int> 1222:89 c6 mov %eax, %esi 1224: 48 8d 3D 6D 0E 00 00 LEA 0xe6d(%rip), %rdi # 2098 <_IO_stdin_used+0x98> 122b: b8 00 00 00 00 MOV $0x0, %eax 1230: e8 1b fe ff ff callq 1050 <printf@plt> return 0; 1235: b8 00 00 00 00 MOV $0x0, %eax 123a: c9 leaveq 123b: C3 retq 123c: 0f 1f 40 00 nopl 0x0(%rax)Copy the code

root@5e3abe332c5a:/home/docker/test4harmony/54# objdump -s ./bin/weharmony ... Got: 1040f30f1efa f2FF25ad 2F00000f 1f440000...... %. /... D.. Contents of section .plt.sec: 1050 f30f1efa f2ff2575 2f00000f 1f440000 ...... %u/.... D.. Contents of section .data: 4000 00000000 00000000 08400000 00000000 ......... @... 4010 33000000 00000000 08200000 00000000 3........ . Contents of section .rodata: 2000 01000200 00000000 68656c6c 6f20776f ........ hello wo 2010 726c6400 00000000 66756e63 5f696e74 rld..... Func_int 2020 20675f69 6e74203D 2025642c 746d7020 g_int = %d, TMP 2030 3D202564 2e0a0066 756e635F 73747220 = %d... func_int 2020 20675f69 6e74203D 2025642c 746d7020 g_int = %d, TMP 2030 3D202564 2e0a0066 756e635F 73747220 = %d... func_str 2040 675f7374 72203d20 25732e0a 00000000 g_str = %s...... 2050 6861726d 6f6e7920 6f730000 00000000 harmony os...... 2060 6d61696e 20e5bc80 e5a78b20 2d20e585 main ...... -.. 2070 a8e5b180 20675f69 6e74203d 2025642c .... G_int = %d, 2080 20e585a8 e5b18020 675f7374 72203D20...... g_str = 2090 25732e0a 00000000 6d61696e 20e7bb93 %s...... main ... 20a0 e69d9f20 2d20e585 a8e5b180 20675f69 ... -... G_i 20b0 6e74203D 2025642c 20e585a8 e5b18020nt = %d,...... 20c0 675f7374 72203d20 25732e0a 00 g_str = %s...Copy the code

Interpretation of the

• The repositioned part of main.o is no longer00 00 00 00Have actual data, such as:

  char *loc_str = "harmony os"; 11d4:48 8D 05 75 0E 00 00 LEA 0xe75(%rip), % RAx # 2050 <_IO_stdin_used+0x50>Copy the code

  The corresponding# 2050 <_IO_stdin_used+0x50>Address data is exactly.rodataThe location of the 2050harmony os

• Look at the main ()

  1209:48 8b 45 f8 mov -0x8(% RBP), %rax 120d: 48 89 c7 mov %rax, %rdi 1210: e8 73 ff ff ff callq 1188 <func_str>Copy the code

  callq 1188 1188It isfunc_strEntry address of

  void func_str(char *str) {
      1188:       f3 0f 1e fa             endbr64
  Copy the code

• Look at global variablesg_str``g_intCorresponding link address0x4018and0x4010

  1215:48 8b 15 fc 2d 00 00 mov 0x2dfc(%rip), % RDX # 4018 <g_str> 1215:48 8b 15 fc 2d 00 00 00 mov 0x2dfc(%rip), % RDX # 4018 <g_str> 1215:48 8b 8b 05 ee 2d 00 00 mov 0x2dee(%rip), %eax # 4010 <g_int>Copy the code

  由.dataArea to provide

  4000 00000000 00000000 08400000 00000000......... @... 4010 33000000 00000000 08200000 00000000 3........ .Copy the code

  0x4010 = 0x33 = 51

• Called in the main functionprintfThe code forcallq 1050

    1230:       e8 1b fe ff ff          callq  1050 <printf@plt>
  Copy the code

  Content by.plt.secZones are provided and discompiled for zones

  Contents of section .plt.sec: 1050 f30f1efa f2ff2575 2f00000f 1f440000 ...... %u/.... D.. Disassembly of section .plt.sec: 0000000000001050 <printf@plt>: 1050: f3 0f 1e fa endbr64 1054: F2 ff 25 75 2f 00 00 BND JMPQ *0x2f75(%rip) # 3fd0 <printf@GLIBC_2.2.5> 105b: 0f 1f 44 00 00 nopl 0x0(%rax, %rax, 1)Copy the code

  Pay attention to3fd0, the runtime environment needs to provide, loader dynamic relocation implementation.

• The bottom line is that WeHarmony has done all of the static relocation of the.o files into a new executable, with only the dynamic linking part remaining, because that requires runtime relocation of addresses. As follows:

objdump -R ./bin/weharmony

root@5e3abe332c5a:/home/docker/test4harmony/54# objdump -R ./bin/weharmony 

./bin/weharmony:     file format elf64-x86-64

DYNAMIC RELOCATION RECORDS
OFFSET           TYPE              VALUE
0000000000003db8 R_X86_64_RELATIVE  *ABS*+0x0000000000001140
0000000000003dc0 R_X86_64_RELATIVE  *ABS*+0x0000000000001100
0000000000004008 R_X86_64_RELATIVE  *ABS*+0x0000000000004008
0000000000004018 R_X86_64_RELATIVE  *ABS*+0x0000000000002008
0000000000003fd8 R_X86_64_GLOB_DAT  _ITM_deregisterTMCloneTable
0000000000003fe0 R_X86_64_GLOB_DAT  __libc_start_main@GLIBC_2.2.5
0000000000003fe8 R_X86_64_GLOB_DAT  __gmon_start__
0000000000003ff0 R_X86_64_GLOB_DAT  _ITM_registerTMCloneTable
0000000000003ff8 R_X86_64_GLOB_DAT  __cxa_finalize@GLIBC_2.2.5
0000000000003fd0 R_X86_64_JUMP_SLOT  printf@GLIBC_2.2.5
Copy the code

Interpretation of the

• This is aweharmonyA diplomatic statement on the runtime environment can be used to integrate with the international community and live in the global village.
• The rest of this instruction is strange. Read a familiar one3fd0, its dynamic link relocation type isR_X86_64_JUMP_SLOT, which tells the dynamic loader to find in the runtime environmentprintfDynamic relocation is completed.

Intensive reading of the kernel source code

Four code stores synchronous annotation kernel source code, >> view the Gitee repository

Analysis of 100 blogs. Dig deep into the core

Add comments to hongmeng kernel source code process, sort out the following article. Content based on the source code, often in life scene analogy as much as possible into the kernel knowledge of a scene, with a pictorial sense, easy to understand memory. It’s important to speak in a way that others can understand! The 100 blogs are by no means a bunch of ridiculously difficult concepts being put forward by Baidu. That’s not interesting. More hope to make the kernel become lifelike, feel more intimate. It’s hard, it’s hard, but there’s no turning back. 😛 and code bugs need to be constantly debug, there will be many mistakes and omissions in the article and annotation content, please forgive, but will be repeatedly amended, continuous update. Xx represents the number of modifications, refined, concise and comprehensive, and strive to create high-quality content.

HongMeng station | into a little bit every day, the original is not easy, welcome to reprint, please indicate the source.