当前位置：首页 > news >正文

鸿蒙内核源码分析(ELF格式篇) | 应用程序入口并不是main

news 文章来源：https://blog.csdn.net/u012165769/article/details/141399304 2025/2/8 23:10:19

阅读之前的说明

先说明，本篇很长，也很枯燥，若不是绝对的技术偏执狂是看不下去的.将通过一段简单代码去跟踪编译成ELF格式后的内容.看看ELF究竟长了怎样的一副花花肠子，用readelf命令去窥视ELF的全貌，最后用objdump命令反汇编ELF.找到了大家熟悉main函数.

开始之前先说结论:

ELF 分四块，其中三块是描述信息(也叫头信息)，另一块是内容，放的是所有段/区的内容.
1. ELF头定义全局性信息
1. Segment(段)头，内容描述段的名字，开始位置，类型，偏移，大小及每段由哪些区组成.
1. 内容区，ELF有两个重要概念 Segment(段) 和 Section(区)，段比区大，二者之间关系如下:
- 每个Segment可以包含多个Section
- 每个Section可以属于多个Segment
- Segment之间可以有重合的部分
- 拿大家熟知的.text，.data，.bss举例，它们都叫区，但它们又属于LOAD段.
1. Section(区)头，内容描述区的名字，开始位置，类型，偏移，大小等信息
ELF一体两面，面对不同的场景扮演不同的角色，这是理解ELF的关键，链接器只关注1，3(区)，4 的内容，加载器只关注1，2，3(段)的内容
鸿蒙对EFL的定义在 kernel\extended\dynload\include\los_ld_elf_pri.h文件中

示例代码

在windows目录E:\harmony\docker\case_code_100下创建 main.c文件，如下:

#include <stdio.h>
void say_hello(char *who)
{printf("hello， %s!\n"， who);
}
char *my_name = "harmony os";int main()
{say_hello(my_name);return 0;
}

做好了环境映射，所以文件会同时出现在docker中.编译生成ELF->运行->readelf -h查看app头部信息.

root@5e3abe332c5a:/home/docker/case_code_100# ls
main.c
root@5e3abe332c5a:/home/docker/case_code_100# gcc -o app main.c
root@5e3abe332c5a:/home/docker/case_code_100# ls
app  main.c
root@5e3abe332c5a:/home/docker/case_code_100# ./app
hello， harmony os!

名正才言顺

一下是关于ELF的所有中英名词对照.建议先仔细看一篇再看系列篇部分.

可执行可连接格式 : ELF(Executable and Linking Format)
ELF文件头:ELF header
基地址:base address
动态连接器: dynamic linker
动态连接: dynamic linking
全局偏移量表: got(global offset table)
进程链接表: plt(Procedure Linkage Table) 
哈希表: hash table
初始化函数 : initialization function
连接编辑器 : link editor
目标文件 : object file
函数连接表 : procedure linkage table
程序头: program header
程序头表 : program header table
程序解析器 : program interpreter
重定位: relocation
共享目标 : shared object
区(节): section
区(节)头 : section header
区(节)表: section header table
段 : segment
字符串表 : string table
符号表: symbol table
终止函数 : termination function

ELF历史

ELF(Executable and Linking Format)，即"可执行可连接格式"，最初由UNIX系统实验室(UNIX System Laboratories – USL)做为应用程序二进制接口(Application Binary Interface - ABI)的一部分而制定和发布.是鸿蒙的主要可执行文件格式.
ELF的最大特点在于它有比较广泛的适用性，通用的二进制接口定义使之可以平滑地移植到多种不同的操作环境上.这样，不需要为每一种操作系统都定义一套不同的接口，因此减少了软件的重复编码与编译，加强了软件的可移植性.

ELF整体布局

ELF规范中把ELF文件宽泛地称为"目标文件 (object file)"，这与我们平时的理解不同.一般地，我们把经过编译但没有连接的文件(比如Unix/Linux上的.o文件)称为目标文件，而ELF文件仅指连接好的可执行文件；在ELF规范中，所有符合ELF格式规范的都称为ELF文件，也称为目标文件，这两个名字是相同的，而经过编译但没有连接的文件则称为"可重定位文件 (relocatable file)“或"待重定位文件 (relocatable file)”.本文采用与此规范相同的命名方式，所以当提到可重定位文件时，一般可以理解为惯常所说的目标文件；而提到目标文件时，即指各种类型的ELF文件.

ELF格式可以表达四种类型的二进制对象文件(object files):

可重定位文件(relocatable file)，用于与其它目标文件进行连接以构建可执行文件或动态链接库.可重定位文件就是常说的目标文件，由源文件编译而成，但还没有连接成可执行文件.在UNIX系统下，一般有扩展名".o".之所以称其为"可重定位"，是因为在这些文件中，如果引用到其它目标文件或库文件中定义的符号（变量或者函数）的话，只是给出一个名字，这里还并不知道这个符号在哪里，其具体的地址是什么.需要在连接的过程中，把对这些外部符号的引用重新定位到其真正定义的位置上，所以称目标文件为"可重定位"或者"待重定位"的.
可执行文件(executable file)包含代码和数据，是可以直接运行的程序.其代码和数据都有固定的地址（或相对于基地址的偏移），系统可根据这些地址信息把程序加载到内存执行.
共享目标文件(shared object file)，即动态连接库文件.它在以下两种情况下被使用:第一，在连接过程中与其它动态链接库或可重定位文件一起构建新的目标文件；第二，在可执行文件被加载的过程中，被动态链接到新的进程中，成为运行代码的一部分.包含了代码和数据，这些数据是在链接时被链接器（ld）和运行时动态链接器（ld.so.l、libc.so.l、ld-linux.so.l）使用的.
核心转储文件(core dump file，就是core dump文件)

可重定位文件用在编译和链接阶段.
可执行文件用在程序运行阶段.
共享库则同时用在编译链接和运行阶段，本篇 app 就是个 DYN，可直接运行.Type:                              DYN (Shared object file)

在不同阶段，我们可以用不同视角来理解ELF文件，整体布局如下图所示:

从上图可见，ELF格式文件整体可分为四大部分:

ELF Header: 在文件的开始，描述整个文件的组织.即readelf -h app看到的内容
Program Header Table: 告诉系统如何创建进程映像.用来构造进程映像的目标文件必须具有程序头部表，可重定位文件可以不需要这个表.表描述所有段(Segment)信息，即readelf -l app看到的前半部分内容.
Segments:段(Segment)由若干区(Section)组成.是从加载器角度来描述 ELF 文件.加载器只关心 ELF header， Program header table 和 Segment 这三部分内容。在加载阶段可以忽略 section header table 来处理程序（所以很多加固手段删除了section header table）
Sections: 是从链接器角度来描述 ELF 文件. 链接器只关心 ELF header，Sections 以及 Section header table 这三部分内容。在链接阶段，可以忽略 program header table 来处理文件.
Section Header Table:描述区(Section)信息的数组，每个元素对应一个区，通常包含在可重定位文件中，可执行文件中为可选(通常包含) 即readelf -S app看到的内容
从图中可以看出 Segment:Section(M:N)是多对多的包含关系.Segment是由多个Section组成，Section也能属于多个段.

ELF头信息

ELF头部信息对应鸿蒙源码结构体为 LDElf32Ehdr，各字段含义已一一注解，很容易理解.

//kernel\extended\dynload\include\los_ld_elf_pri.h
/* Elf header */
#define LD_EI_NIDENT           16
typedef struct {UINT8       elfIdent[LD_EI_NIDENT]; /* Magic number and other info *///含前16个字节，又可细分成class、data、version等字段，具体含义不用太关心，只需知道前4个字节点包含`ELF`关键字，这样可以判断当前文件是否是ELF格式UINT16      elfType;                /* Object file type *///表示具体ELF类型，可重定位文件/可执行文件/共享库文件UINT16      elfMachine;             /* Architecture *///表示cpu架构UINT32      elfVersion;             /* Object file version *///表示文件版本号UINT32      elfEntry;               /* Entry point virtual address *///对应`Entry point address`，程序入口函数地址，通过进程虚拟地址空间地址表达UINT32      elfPhoff;               /* Program header table file offset *///对应`Start of program headers`，表示program header table在文件内的偏移位置UINT32      elfShoff;               /* Section header table file offset *///对应`Start of section headers`，表示section header table在文件内的偏移位置UINT32      elfFlags;               /* Processor-specific flags *///表示与CPU处理器架构相关的信息UINT16      elfHeadSize;            /* ELF header size in bytes *///对应`Size of this header`，表示本ELF header自身的长度UINT16      elfPhEntSize;           /* Program header table entry size *///对应`Size of program headers`，表示program header table中每个元素的大小UINT16      elfPhNum;               /* Program header table entry count *///对应`Number of program headers`，表示program header table中元素个数UINT16      elfShEntSize;           /* Section header table entry size *///对应`Size of section headers`，表示section header table中每个元素的大小UINT16      elfShNum;               /* Section header table entry count *///对应`Number of section headers`，表示section header table中元素的个数UINT16      elfShStrIndex;          /* Section header string table index *///对应`Section header string table index`，表示描述各section字符名称的string table在section header table中的下标
} LDElf32Ehdr;
root@5e3abe332c5a:/home/docker/case_code_100# readelf -h app
ELF Header:Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00Class:                             ELF64Data:                              2's complement， little endianVersion:                           1 (current)OS/ABI:                            UNIX - System VABI Version:                       0Type:                              DYN (Shared object file)Machine:                           Advanced Micro Devices X86-64Version:                           0x1Entry point address:               0x1060Start of program headers:          64 (bytes into file)Start of section headers:          14784 (bytes into file)Flags:                             0x0Size of this header:               64 (bytes)Size of program headers:           56 (bytes)Number of program headers:         13Size of section headers:           64 (bytes)Number of section headers:         31Section header string table index: 30

解读

显示的信息，就是 ELF header 中描述的所有内容了。这个内容与结构体 LDElf32Ehdr 中的成员变量是一一对应的！
Size of this header: 64 (bytes)也就是说：ELF header 部分的内容，一共是 64 个字节。64个字节码长啥样可以用命令od -Ax -t x1 -N 64 app看，并对照结构体LDElf32Ehdr来理解.

root@5e3abe332c5a:/home/docker/case_code_100/51# od -Ax -t x1 -N 64 app
000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
000010 03 00 3e 00 01 00 00 00 60 10 00 00 00 00 00 00
000020 40 00 00 00 00 00 00 00 c0 39 00 00 00 00 00 00
000030 00 00 00 00 40 00 38 00 0d 00 40 00 1f 00 1e 00
000040

简单解释一下命令的几个选项：

-Ax: 显示地址的时候，用十六进制来表示。如果使用 -Ad，意思就是用十进制来显示地址;
-t -x1: 显示字节码内容的时候，使用十六进制(x)，每次显示一个字节(1);
-N 64：只需要读取64个字节;

这里留意这几个内容，下面会说明，先记住.

Entry point address:               0x1060   //代码区 .text 起始位置，即程序运行开始位置
Size of program headers:           56 (bytes)//每个段头大小
Number of program headers:         13       //段数量
Size of section headers:           64 (bytes)//每个区头大小
Number of section headers:         31       //区数量
Section header string table index: 30       //字符串数组索引，该区记录所有区名称

段(Segment)头信息

段(Segment)信息对应鸿蒙源码结构体为 LDElf32Phdr，

//kernel\extended\dynload\include\los_ld_elf_pri.h
/* Program Header */
typedef struct {UINT32 type;     /* Segment type */	//段类型UINT32 offset;   /* Segment file offset */		//此数据成员给出本段内容在文件中的位置，即段内容的开始位置相对于文件开头的偏移量.UINT32 vAddr;    /* Segment virtual address */	//此数据成员给出本段内容的开始位置在进程空间中的虚拟地址.UINT32 phyAddr;  /* Segment physical address */	//此数据成员给出本段内容的开始位置在进程空间中的物理地址.对于目前大多数现代操作系统而言，应用程序中段的物理地址事先是不可知的，所以目前这个成员多数情况下保留不用，或者被操作系统改作它用.UINT32 fileSize; /* Segment size in file */		//此数据成员给出本段内容在文件中的大小，单位是字节，可以是0.UINT32 memSize;  /* Segment size in memory */	//此数据成员给出本段内容在内容镜像中的大小，单位是字节，可以是0.UINT32 flags;    /* Segment flags */			//此数据成员给出了本段内容的属性.UINT32 align;    /* Segment alignment */		//对于可装载的段来说，其p_vaddr和p_offset的值至少要向内存页面大小对齐.
} LDElf32Phdr;

解读
用readelf -l查看app段头部表内容，先看命令返回的前半部分:

root@5e3abe332c5a:/home/docker/case_code_100# readelf -l app 
Elf file type is DYN (Shared object file)
Entry point 0x1060
There are 13 program headers， starting at offset 64
Program Headers:Type           Offset             VirtAddr           PhysAddrFileSiz            MemSiz              Flags  AlignPHDR           0x0000000000000040 0x0000000000000040 0x00000000000000400x00000000000002d8 0x00000000000002d8  R      0x8INTERP         0x0000000000000318 0x0000000000000318 0x00000000000003180x000000000000001c 0x000000000000001c  R      0x1[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]LOAD           0x0000000000000000 0x0000000000000000 0x00000000000000000x0000000000000618 0x0000000000000618  R      0x1000LOAD           0x0000000000001000 0x0000000000001000 0x00000000000010000x0000000000000225 0x0000000000000225  R E    0x1000LOAD           0x0000000000002000 0x0000000000002000 0x00000000000020000x0000000000000190 0x0000000000000190  R      0x1000LOAD           0x0000000000002db8 0x0000000000003db8 0x0000000000003db80x0000000000000260 0x0000000000000268  RW     0x1000DYNAMIC        0x0000000000002dc8 0x0000000000003dc8 0x0000000000003dc80x00000000000001f0 0x00000000000001f0  RW     0x8NOTE           0x0000000000000338 0x0000000000000338 0x00000000000003380x0000000000000020 0x0000000000000020  R      0x8NOTE           0x0000000000000358 0x0000000000000358 0x00000000000003580x0000000000000044 0x0000000000000044  R      0x4GNU_PROPERTY   0x0000000000000338 0x0000000000000338 0x00000000000003380x0000000000000020 0x0000000000000020  R      0x8GNU_EH_FRAME   0x000000000000201c 0x000000000000201c 0x000000000000201c0x000000000000004c 0x000000000000004c  R      0x4GNU_STACK      0x0000000000000000 0x0000000000000000 0x00000000000000000x0000000000000000 0x0000000000000000  RW     0x10GNU_RELRO      0x0000000000002db8 0x0000000000003db8 0x0000000000003db80x0000000000000248 0x0000000000000248  R      0x1

数一下一共13个段，其实在ELF头信息也告诉了我们共13个段

Size of program headers:           56 (bytes)//每个段头大小
Number of program headers:         13       //段数量

仔细看下这些段的开始地址和大小，发现有些段是重叠的.那是因为一个区可以被多个段所拥有.例如:0x2db8 对应的 .init_array区就被第四LOAD 和 GNU_RELRO两段所共有.

PHDR，此类型header元素描述了program header table自身的信息.从这里的内容看出，示例程序的program header table在文件中的偏移(Offset)为0x40，即64号字节处.该段映射到进程空间的虚拟地址(VirtAddr)为0x40.PhysAddr暂时不用，其保持和VirtAddr一致.该段占用的文件大小FileSiz为0x2d8.运行时占用进程空间内存大小MemSiz也为0x2d8.Flags标记表示该段的读写权限，这里R表示只读，Align对齐为8，表明本段按8字节对齐.

INTERP，此类型header元素描述了一个特殊内存段，该段内存记录了动态加载解析器的访问路径字符串.示例程序中，该段内存位于文件偏移0x318处，即紧跟program header table.映射的进程虚拟地址空间地址为0x318.文件长度和内存映射长度均为0x1c，即28个字符，具体内容为/lib64/ld-linux-x86-64.so.2.段属性为只读，并按字节对齐.

LOAD，此类型header元素描述了可加载到进程空间的代码区或数据区:

其第二段包含了代码区，文件内偏移为0x1000，文件大小为0x225，映射到进程地址0x001000处，属性为只读可执行(RE)，段地址按0x1000(4K)边界对齐.
其第四段包含了数据区，文件内偏移为0x2db8，文件大小为0x260，映射到进程地址0x003db8处，属性为可读可写(RW)，段地址也按0x1000(4K)边界对齐.

DYNAMIC，此类型header元素描述了动态加载段，其内部通常包含了一个名为.dynamic的动态加载区.这也是一个数组，每个元素描述了与动态加载相关的各方面信息，将在系列篇(动态加载篇)中介绍.该段是从文件偏移0x2dc8处开始，长度为0x1f0，并映射到进程的0x3dc8.可见该段和上一个段LOAD4 0x2db8是有重叠的.

GNU_STACK，可执行栈，即栈区，在加载段的过程中，当发现存在PT_GNU_STACK，也就是GNU_STACK segment 的存在，如果存在这个这个段的话，看这个段的 flags 是否有可执行权限，来设置对应的值.必须为RW方式.

再看命令返回内容的后半部分-段区映射关系

 Section to Segment mapping:Segment Sections...0001     .interp02     .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt03     .init .plt .plt.got .plt.sec .text .fini04     .rodata .eh_frame_hdr .eh_frame05     .init_array .fini_array .dynamic .got .data .bss06     .dynamic07     .note.gnu.property08     .note.gnu.build-id .note.ABI-tag09     .note.gnu.property10     .eh_frame_hdr1112     .init_array .fini_array .dynamic .got

13个段和31个区的映射关系，右边其实不止31个区，是因为一个区可以共属于多个段，例如 .dynamic ，.interp，.got
Segment:Section(M:N)是多对多的包含关系.Segment是由多个Section组成，Section也能属于多个段.这个很重要，说第二遍了.

INTERP段只包含了.interp区
LOAD2段包含.interp、.plt、.text等区，.text代码区位于这个段. 这个段是 'RE’属性，只读可执行的.
LOAD4包含.dynamic、.data、.bss等区，数据区位于这个段.这个段是 'RW’属性，可读可写. .data、.bss都是数据区，有何区别呢?
.data(ZI data)它用来存放初始化了的(initailized)全局变量(global)和初始化了的静态变量(static).
.bss(RW data )它用来存放未初始化的(uninitailized)全局变量(global)和未初始化的静态变量.
DYNAMIC段包含.dynamic区.

区表

区(section)头表信息对应鸿蒙源码结构体为 LDElf32Shdr，

//kernel\extended\dynload\include\los_ld_elf_pri.h
/* Section header */
typedef struct {UINT32 shName;      /* Section name (string tbl index) *///表示每个区的名字UINT32 shType;      /* Section type *///表示每个区的功能UINT32 shFlags;     /* Section flags *///表示每个区的属性UINT32 shAddr;      /* Section virtual addr at execution *///表示每个区的进程映射地址UINT32 shOffset;    /* Section file offset *///表示文件内偏移UINT32 shSize;      /* Section size in bytes *///表示区的大小UINT32 shLink;      /* Link to another section *///Link和Info记录不同类型区的相关信息UINT32 shInfo;      /* Additional section information *///Link和Info记录不同类型区的相关信息UINT32 shAddrAlign; /* Section alignment *///表示区的对齐单位UINT32 shEntSize;   /* Entry size if section holds table *///表示区中每个元素的大小(如果该区为一个数组的话，否则该值为0)
} LDElf32Shdr;

示例程序共生成31个区.其实在头文件中也已经告诉我们了

Size of section headers:           64 (bytes)//每个区头大小
Number of section headers:         31       //区数量

通过readelf -S命令看看示例程序中 section header table的内容，如下所示.

root@5e3abe332c5a:/home/docker/case_code_100# readelf -S app
There are 31 section headers， starting at offset 0x39c0:Section Headers:[Nr] Name              Type             Address           OffsetSize              EntSize          Flags  Link  Info  Align[ 0]                   NULL             0000000000000000  000000000000000000000000  0000000000000000           0     0     0[ 1] .interp           PROGBITS         0000000000000318  00000318000000000000001c  0000000000000000   A       0     0     1[ 2] .note.gnu.propert NOTE             0000000000000338  000003380000000000000020  0000000000000000   A       0     0     8[ 3] .note.gnu.build-i NOTE             0000000000000358  000003580000000000000024  0000000000000000   A       0     0     4[ 4] .note.ABI-tag     NOTE             000000000000037c  0000037c0000000000000020  0000000000000000   A       0     0     4[ 5] .gnu.hash         GNU_HASH         00000000000003a0  000003a00000000000000024  0000000000000000   A       6     0     8[ 6] .dynsym           DYNSYM           00000000000003c8  000003c800000000000000a8  0000000000000018   A       7     1     8[ 7] .dynstr           STRTAB           0000000000000470  000004700000000000000084  0000000000000000   A       0     0     1[ 8] .gnu.version      VERSYM           00000000000004f4  000004f4000000000000000e  0000000000000002   A       6     0     2[ 9] .gnu.version_r    VERNEED          0000000000000508  000005080000000000000020  0000000000000000   A       7     1     8[10] .rela.dyn         RELA             0000000000000528  0000052800000000000000d8  0000000000000018   A       6     0     8[11] .rela.plt         RELA             0000000000000600  000006000000000000000018  0000000000000018  AI       6    24     8[12] .init             PROGBITS         0000000000001000  00001000000000000000001b  0000000000000000  AX       0     0     4[13] .plt              PROGBITS         0000000000001020  000010200000000000000020  0000000000000010  AX       0     0     16[14] .plt.got          PROGBITS         0000000000001040  000010400000000000000010  0000000000000010  AX       0     0     16[15] .plt.sec          PROGBITS         0000000000001050  000010500000000000000010  0000000000000010  AX       0     0     16[16] .text             PROGBITS         0000000000001060  0000106000000000000001b5  0000000000000000  AX       0     0     16[17] .fini             PROGBITS         0000000000001218  00001218000000000000000d  0000000000000000  AX       0     0     4[18] .rodata           PROGBITS         0000000000002000  00002000000000000000001b  0000000000000000   A       0     0     4[19] .eh_frame_hdr     PROGBITS         000000000000201c  0000201c000000000000004c  0000000000000000   A       0     0     4[20] .eh_frame         PROGBITS         0000000000002068  000020680000000000000128  0000000000000000   A       0     0     8[21] .init_array       INIT_ARRAY       0000000000003db8  00002db80000000000000008  0000000000000008  WA       0     0     8[22] .fini_array       FINI_ARRAY       0000000000003dc0  00002dc00000000000000008  0000000000000008  WA       0     0     8[23] .dynamic          DYNAMIC          0000000000003dc8  00002dc800000000000001f0  0000000000000010  WA       7     0     8[24] .got              PROGBITS         0000000000003fb8  00002fb80000000000000048  0000000000000008  WA       0     0     8[25] .data             PROGBITS         0000000000004000  000030000000000000000018  0000000000000000  WA       0     0     8[26] .bss              NOBITS           0000000000004018  000030180000000000000008  0000000000000000  WA       0     0     1[27] .comment          PROGBITS         0000000000000000  00003018000000000000002a  0000000000000001  MS       0     0     1[28] .symtab           SYMTAB           0000000000000000  000030480000000000000648  0000000000000018          29    46     8[29] .strtab           STRTAB           0000000000000000  000036900000000000000216  0000000000000000           0     0     1[30] .shstrtab         STRTAB           0000000000000000  000038a6000000000000011a  0000000000000000           0     0     1
Key to Flags:W (write)， A (alloc)， X (execute)， M (merge)， S (strings)， I (info)，L (link order)， O (extra OS processing required)， G (group)， T (TLS)，C (compressed)， x (unknown)， o (OS specific)， E (exclude)，l (large)， p (processor specific)

String Table

在 ELF header 的最后 2 个字节是 0x1e 0x00，即30. 它对应结构体中的成员 elfShStrIndex，意思是这个 ELF 文件中，字符串表是一个普通的 Section，在这个 Section 中，存储了 ELF 文件中使用到的所有的字符串。
我们使用readelf -x读出下标30区的数据:

root@5e3abe332c5a:/home/docker/case_code_100# readelf -x 30 app Hex dump of section '.shstrtab':0x00000000 002e7379 6d746162 002e7374 72746162 ..symtab..strtab0x00000010 002e7368 73747274 6162002e 696e7465 ..shstrtab..inte0x00000020 7270002e 6e6f7465 2e676e75 2e70726f rp..note.gnu.pro0x00000030 70657274 79002e6e 6f74652e 676e752e perty..note.gnu.0x00000040 6275696c 642d6964 002e6e6f 74652e41 build-id..note.A0x00000050 42492d74 6167002e 676e752e 68617368 BI-tag..gnu.hash0x00000060 002e6479 6e73796d 002e6479 6e737472 ..dynsym..dynstr0x00000070 002e676e 752e7665 7273696f 6e002e67 ..gnu.version..g0x00000080 6e752e76 65727369 6f6e5f72 002e7265 nu.version_r..re0x00000090 6c612e64 796e002e 72656c61 2e706c74 la.dyn..rela.plt0x000000a0 002e696e 6974002e 706c742e 676f7400 ..init..plt.got.0x000000b0 2e706c74 2e736563 002e7465 7874002e .plt.sec..text..0x000000c0 66696e69 002e726f 64617461 002e6568 fini..rodata..eh0x000000d0 5f667261 6d655f68 6472002e 65685f66 _frame_hdr..eh_f0x000000e0 72616d65 002e696e 69745f61 72726179 rame..init_array0x000000f0 002e6669 6e695f61 72726179 002e6479 ..fini_array..dy0x00000100 6e616d69 63002e64 61746100 2e627373 namic..data..bss0x00000110 002e636f 6d6d656e 7400              ..comment.

可以发现，这里其实是一堆字符串，这些字符串对应的就是各个区的名字.因此section header table中每个元素的Name字段其实是这个string table的索引.为节省空间而做的设计，再回头看看ELF header中的 elfShStrIndex，

Section header string table index: 30 //字符串数组索引，该区记录所有区名称

它的值正好就是30，指向了当前的string table.

符号表 Symbol Table

Section Header Table中，还有一类SYMTAB(DYNSYM)区，该区叫符号表.符号表中的每个元素对应一个符号，记录了每个符号对应的实际数值信息，通常用在重定位过程中或问题定位过程中，进程执行阶段并不加载符号表.符号表对应鸿蒙源码结构体为 LDElf32Sym.
//kernel\extended\dynload\include\los_ld_elf_pri.h

/* Symbol table */
typedef struct {UINT32 stName;  /* Symbol table name (string tbl index) *///表示符号对应的源码字符串，为对应String Table中的索引UINT32 stValue; /* Symbol table value *///表示符号对应的数值UINT32 stSize;  /* Symbol table size *///表示符号对应数值的空间占用大小UINT8 stInfo;   /* Symbol table type and binding *///表示符号的相关信息 如符号类型(变量符号、函数符号)UINT8 stOther;  /* Symbol table visibility */UINT16 stShndx; /* Section table index *///表示与该符号相关的区的索引，例如函数符号与对应的代码区相关
} LDElf32Sym;

用readelf -s读出示例程序中的符号表，如下所示

root@5e3abe332c5a:/home/docker/case_code_100# readelf -s appSymbol table '.dynsym' contains 7 entries:Num:    Value          Size Type    Bind   Vis      Ndx Name0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND1: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5 (2)3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable6: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (2)Symbol table '.symtab' contains 67 entries:Num:    Value          Size Type    Bind   Vis      Ndx Name0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND1: 0000000000000318     0 SECTION LOCAL  DEFAULT    12: 0000000000000338     0 SECTION LOCAL  DEFAULT    23: 0000000000000358     0 SECTION LOCAL  DEFAULT    34: 000000000000037c     0 SECTION LOCAL  DEFAULT    45: 00000000000003a0     0 SECTION LOCAL  DEFAULT    56: 00000000000003c8     0 SECTION LOCAL  DEFAULT    67: 0000000000000470     0 SECTION LOCAL  DEFAULT    78: 00000000000004f4     0 SECTION LOCAL  DEFAULT    89: 0000000000000508     0 SECTION LOCAL  DEFAULT    910: 0000000000000528     0 SECTION LOCAL  DEFAULT   1011: 0000000000000600     0 SECTION LOCAL  DEFAULT   1112: 0000000000001000     0 SECTION LOCAL  DEFAULT   1213: 0000000000001020     0 SECTION LOCAL  DEFAULT   1314: 0000000000001040     0 SECTION LOCAL  DEFAULT   1415: 0000000000001050     0 SECTION LOCAL  DEFAULT   1516: 0000000000001060     0 SECTION LOCAL  DEFAULT   1617: 0000000000001218     0 SECTION LOCAL  DEFAULT   1718: 0000000000002000     0 SECTION LOCAL  DEFAULT   1819: 000000000000201c     0 SECTION LOCAL  DEFAULT   1920: 0000000000002068     0 SECTION LOCAL  DEFAULT   2021: 0000000000003db8     0 SECTION LOCAL  DEFAULT   2122: 0000000000003dc0     0 SECTION LOCAL  DEFAULT   2223: 0000000000003dc8     0 SECTION LOCAL  DEFAULT   2324: 0000000000003fb8     0 SECTION LOCAL  DEFAULT   2425: 0000000000004000     0 SECTION LOCAL  DEFAULT   2526: 0000000000004018     0 SECTION LOCAL  DEFAULT   2627: 0000000000000000     0 SECTION LOCAL  DEFAULT   2728: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c29: 0000000000001090     0 FUNC    LOCAL  DEFAULT   16 deregister_tm_clones30: 00000000000010c0     0 FUNC    LOCAL  DEFAULT   16 register_tm_clones31: 0000000000001100     0 FUNC    LOCAL  DEFAULT   16 __do_global_dtors_aux32: 0000000000004018     1 OBJECT  LOCAL  DEFAULT   26 completed.806033: 0000000000003dc0     0 OBJECT  LOCAL  DEFAULT   22 __do_global_dtors_aux_fin34: 0000000000001140     0 FUNC    LOCAL  DEFAULT   16 frame_dummy35: 0000000000003db8     0 OBJECT  LOCAL  DEFAULT   21 __frame_dummy_init_array_36: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS main.c37: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c38: 000000000000218c     0 OBJECT  LOCAL  DEFAULT   20 __FRAME_END__39: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS40: 0000000000003dc0     0 NOTYPE  LOCAL  DEFAULT   21 __init_array_end41: 0000000000003dc8     0 OBJECT  LOCAL  DEFAULT   23 _DYNAMIC42: 0000000000003db8     0 NOTYPE  LOCAL  DEFAULT   21 __init_array_start43: 000000000000201c     0 NOTYPE  LOCAL  DEFAULT   19 __GNU_EH_FRAME_HDR44: 0000000000003fb8     0 OBJECT  LOCAL  DEFAULT   24 _GLOBAL_OFFSET_TABLE_45: 0000000000001000     0 FUNC    LOCAL  DEFAULT   12 _init46: 0000000000001210     5 FUNC    GLOBAL DEFAULT   16 __libc_csu_fini47: 0000000000004010     8 OBJECT  GLOBAL DEFAULT   25 my_name48: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab49: 0000000000004000     0 NOTYPE  WEAK   DEFAULT   25 data_start50: 0000000000004018     0 NOTYPE  GLOBAL DEFAULT   25 _edata51: 0000000000001218     0 FUNC    GLOBAL HIDDEN    17 _fini52: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@@GLIBC_2.2.553: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@@GLIBC_54: 0000000000004000     0 NOTYPE  GLOBAL DEFAULT   25 __data_start55: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__56: 0000000000004008     0 OBJECT  GLOBAL HIDDEN    25 __dso_handle57: 0000000000002000     4 OBJECT  GLOBAL DEFAULT   18 _IO_stdin_used58: 00000000000011a0   101 FUNC    GLOBAL DEFAULT   16 __libc_csu_init59: 0000000000004020     0 NOTYPE  GLOBAL DEFAULT   26 _end60: 0000000000001060    47 FUNC    GLOBAL DEFAULT   16 _start61: 0000000000004018     0 NOTYPE  GLOBAL DEFAULT   26 __bss_start62: 0000000000001174    30 FUNC    GLOBAL DEFAULT   16 main63: 0000000000001149    43 FUNC    GLOBAL DEFAULT   16 say_hello64: 0000000000004018     0 OBJECT  GLOBAL HIDDEN    25 __TMC_END__65: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable66: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@@GLIBC_2.2

在最后位置找到了亲切的老朋友 main和say_hello

    62: 0000000000001174    30 FUNC    GLOBAL DEFAULT   16 main63: 0000000000001149    43 FUNC    GLOBAL DEFAULT   16 say_hello

main函数符号对应的数值为0x1174，其类型为FUNC，大小为30字节，对应的代码区索引为16.
say_hello函数符号对应数值为0x1149，其类型为FUNC，大小为43字节，对应的代码区索引同为16.
Section Header Table:

  [16] .text             PROGBITS         0000000000001060  0000106000000000000001b5  0000000000000000  AX       0     0     16

反汇编代码区

在理解了String Table和Symbol Table的作用后，通过objdump反汇编来理解一下.text代码区:

root@5e3abe332c5a:/home/docker/case_code_100# objdump -j .text -l -C -S app0000000000001149 <say_hello>:
say_hello():1149:       f3 0f 1e fa             endbr64114d:       55                      push   %rbp114e:       48 89 e5                mov    %rsp，%rbp1151:       48 83 ec 10             sub    $0x10，%rsp1155:       48 89 7d f8             mov    %rdi，-0x8(%rbp)1159:       48 8b 45 f8             mov    -0x8(%rbp)，%rax115d:       48 89 c6                mov    %rax，%rsi1160:       48 8d 3d 9d 0e 00 00    lea    0xe9d(%rip)，%rdi        # 2004 <_IO_stdin_used+0x4>1167:       b8 00 00 00 00          mov    $0x0，%eax116c:       e8 df fe ff ff          callq  1050 <printf@plt>1171:       90                      nop1172:       c9                      leaveq1173:       c3                      retq0000000000001174 <main>:
main():1174:       f3 0f 1e fa             endbr641178:       55                      push   %rbp1179:       48 89 e5                mov    %rsp，%rbp117c:       48 8b 05 8d 2e 00 00    mov    0x2e8d(%rip)，%rax        # 4010 <my_name>1183:       48 89 c7                mov    %rax，%rdi1186:       e8 be ff ff ff          callq  1149 <say_hello>118b:       b8 00 00 00 00          mov    $0x0，%eax1190:       5d                      pop    %rbp1191:       c3                      retq1192:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax，%rax，1)1199:       00 00 00119c:       0f 1f 40 00             nopl   0x0(%rax)

0x1149 0x1174正是say_hello，main函数的入口地址.并看到了激动人心的指令

1186:       e8 be ff ff ff          callq  1149 <say_hello>

很佩服你还能看到这里，牛逼，牛逼! 看了这么久还记得开头的C代码的样子吗? 再看一遍 : )

#include <stdio.h>
void say_hello(char *who)
{printf("hello， %s!\n"， who);
}
char *my_name = "harmony os";
int main()
{say_hello(my_name);return 0;
}
root@5e3abe332c5a:/home/docker/case_code_100# ./app
hello， harmony os!

但是!!! 晕，怎么还有but，西卡西…，上面请大家记住的还有一个地方没说到

Entry point address:               0x1060   //代码区 .text 起始位置，即程序运行开始位置

它的地址并不是main函数位置0x1174，是0x1060!而且代码区的开始位置是0x1060没错的.

  [16] .text             PROGBITS         0000000000001060  0000106000000000000001b5  0000000000000000  AX       0     0     16

难度main不是入口地址? 那0x1060上放的是何方神圣，再查符号表发现是

    60: 0000000000001060    47 FUNC    GLOBAL DEFAULT   16 _start

从反汇编堆中找到 _start

0000000000001060 <_start>:
_start():1060:       f3 0f 1e fa             endbr641064:       31 ed                   xor    %ebp，%ebp1066:       49 89 d1                mov    %rdx，%r91069:       5e                      pop    %rsi106a:       48 89 e2                mov    %rsp，%rdx106d:       48 83 e4 f0             and    $0xfffffffffffffff0，%rsp1071:       50                      push   %rax1072:       54                      push   %rsp1073:       4c 8d 05 96 01 00 00    lea    0x196(%rip)，%r8        # 1210 <__libc_csu_fini>107a:       48 8d 0d 1f 01 00 00    lea    0x11f(%rip)，%rcx        # 11a0 <__libc_csu_init>1081:       48 8d 3d ec 00 00 00    lea    0xec(%rip)，%rdi        # 1174 <main>1088:       ff 15 52 2f 00 00       callq  *0x2f52(%rip)        # 3fe0 <__libc_start_main@GLIBC_2.2.5>108e:       f4                      hlt108f:       90                      nop

这才看到了0x1174的main函数.所以真正的说法是:

从内核动态加载的视角看，程序运行首个函数并不是main，而是_start.
但从应用程序开发者视角看，main就是启动函数.

经常有很多小伙伴抱怨说：不知道学习鸿蒙开发哪些技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？

为了能够帮助到大家能够有规划的学习，这里特别整理了一套纯血版鸿蒙（HarmonyOS Next）全栈开发技术的学习路线，包含了鸿蒙开发必掌握的核心知识要点，内容有（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、WebGL、元服务、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony驱动开发、系统定制移植等等）鸿蒙（HarmonyOS NEXT）技术知识点。

在这里插入图片描述