阅读之前的说明
先说明，本篇很长，也很枯燥，若不是绝对的技术偏执狂是看不下去的.将通过一段简单代码去跟踪编译成ELF格式后的内容.看看ELF究竟长了怎样的一副花花肠子，用readelf命令去窥视ELF的全貌，最后用objdump命令反汇编ELF.找到了大家熟悉main函数.
开始之前先说结论:
- ELF 分四块，其中三块是描述信息(也叫头信息)，另一块是内容，放的是所有段/区的内容.
- ELF头定义全局性信息
- Segment(段)头，内容描述段的名字，开始位置，类型，偏移，大小及每段由哪些区组成.
- 内容区，ELF有两个重要概念
Segment(段) 和Section(区)，段比区大，二者之间关系如下:
- 每个
Segment可以包含多个Section - 每个
Section可以属于多个Segment -
Segment之间可以有重合的部分 - 拿大家熟知的
.text，.data，.bss举例，它们都叫区，但它们又属于LOAD段.
- 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 functionELF历史
- 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 00
Class: ELF64
Data: 2's complement， little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x1060
Start of program headers: 64 (bytes into file)
Start of section headers: 14784 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
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解读
显示的信息，就是 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 PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000002d8 0x00000000000002d8 R 0x8
INTERP 0x0000000000000318 0x0000000000000318 0x0000000000000318
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000618 0x0000000000000618 R 0x1000
LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000
0x0000000000000225 0x0000000000000225 R E 0x1000
LOAD 0x0000000000002000 0x0000000000002000 0x0000000000002000
0x0000000000000190 0x0000000000000190 R 0x1000
LOAD 0x0000000000002db8 0x0000000000003db8 0x0000000000003db8
0x0000000000000260 0x0000000000000268 RW 0x1000
DYNAMIC 0x0000000000002dc8 0x0000000000003dc8 0x0000000000003dc8
0x00000000000001f0 0x00000000000001f0 RW 0x8
NOTE 0x0000000000000338 0x0000000000000338 0x0000000000000338
0x0000000000000020 0x0000000000000020 R 0x8
NOTE 0x0000000000000358 0x0000000000000358 0x0000000000000358
0x0000000000000044 0x0000000000000044 R 0x4
GNU_PROPERTY 0x0000000000000338 0x0000000000000338 0x0000000000000338
0x0000000000000020 0x0000000000000020 R 0x8
GNU_EH_FRAME 0x000000000000201c 0x000000000000201c 0x000000000000201c
0x000000000000004c 0x000000000000004c R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x0000000000002db8 0x0000000000003db8 0x0000000000003db8
0x0000000000000248 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...
00
01 .interp
02 .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt
03 .init .plt .plt.got .plt.sec .text .fini
04 .rodata .eh_frame_hdr .eh_frame
05 .init_array .fini_array .dynamic .got .data .bss
06 .dynamic
07 .note.gnu.property
08 .note.gnu.build-id .note.ABI-tag
09 .note.gnu.property
10 .eh_frame_hdr
11
12 .init_array .fini_array .dynamic .got13个段和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 Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .interp PROGBITS 0000000000000318 00000318
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.gnu.propert NOTE 0000000000000338 00000338
0000000000000020 0000000000000000 A 0 0 8
[ 3] .note.gnu.build-i NOTE 0000000000000358 00000358
0000000000000024 0000000000000000 A 0 0 4
[ 4] .note.ABI-tag NOTE 000000000000037c 0000037c
0000000000000020 0000000000000000 A 0 0 4
[ 5] .gnu.hash GNU_HASH 00000000000003a0 000003a0
0000000000000024 0000000000000000 A 6 0 8
[ 6] .dynsym DYNSYM 00000000000003c8 000003c8
00000000000000a8 0000000000000018 A 7 1 8
[ 7] .dynstr STRTAB 0000000000000470 00000470
0000000000000084 0000000000000000 A 0 0 1
[ 8] .gnu.version VERSYM 00000000000004f4 000004f4
000000000000000e 0000000000000002 A 6 0 2
[ 9] .gnu.version_r VERNEED 0000000000000508 00000508
0000000000000020 0000000000000000 A 7 1 8
[10] .rela.dyn RELA 0000000000000528 00000528
00000000000000d8 0000000000000018 A 6 0 8
[11] .rela.plt RELA 0000000000000600 00000600
0000000000000018 0000000000000018 AI 6 24 8
[12] .init PROGBITS 0000000000001000 00001000
000000000000001b 0000000000000000 AX 0 0 4
[13] .plt PROGBITS 0000000000001020 00001020
0000000000000020 0000000000000010 AX 0 0 16
[14] .plt.got PROGBITS 0000000000001040 00001040
0000000000000010 0000000000000010 AX 0 0 16
[15] .plt.sec PROGBITS 0000000000001050 00001050
0000000000000010 0000000000000010 AX 0 0 16
[16] .text PROGBITS 0000000000001060 00001060
00000000000001b5 0000000000000000 AX 0 0 16
[17] .fini PROGBITS 0000000000001218 00001218
000000000000000d 0000000000000000 AX 0 0 4
[18] .rodata PROGBITS 0000000000002000 00002000
000000000000001b 0000000000000000 A 0 0 4
[19] .eh_frame_hdr PROGBITS 000000000000201c 0000201c
000000000000004c 0000000000000000 A 0 0 4
[20] .eh_frame PROGBITS 0000000000002068 00002068
0000000000000128 0000000000000000 A 0 0 8
[21] .init_array INIT_ARRAY 0000000000003db8 00002db8
0000000000000008 0000000000000008 WA 0 0 8
[22] .fini_array FINI_ARRAY 0000000000003dc0 00002dc0
0000000000000008 0000000000000008 WA 0 0 8
[23] .dynamic DYNAMIC 0000000000003dc8 00002dc8
00000000000001f0 0000000000000010 WA 7 0 8
[24] .got PROGBITS 0000000000003fb8 00002fb8
0000000000000048 0000000000000008 WA 0 0 8
[25] .data PROGBITS 0000000000004000 00003000
0000000000000018 0000000000000000 WA 0 0 8
[26] .bss NOBITS 0000000000004018 00003018
0000000000000008 0000000000000000 WA 0 0 1
[27] .comment PROGBITS 0000000000000000 00003018
000000000000002a 0000000000000001 MS 0 0 1
[28] .symtab SYMTAB 0000000000000000 00003048
0000000000000648 0000000000000018 29 46 8
[29] .strtab STRTAB 0000000000000000 00003690
0000000000000216 0000000000000000 0 0 1
[30] .shstrtab STRTAB 0000000000000000 000038a6
000000000000011a 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..strtab
0x00000010 002e7368 73747274 6162002e 696e7465 ..shstrtab..inte
0x00000020 7270002e 6e6f7465 2e676e75 2e70726f rp..note.gnu.pro
0x00000030 70657274 79002e6e 6f74652e 676e752e perty..note.gnu.
0x00000040 6275696c 642d6964 002e6e6f 74652e41 build-id..note.A
0x00000050 42492d74 6167002e 676e752e 68617368 BI-tag..gnu.hash
0x00000060 002e6479 6e73796d 002e6479 6e737472 ..dynsym..dynstr
0x00000070 002e676e 752e7665 7273696f 6e002e67 ..gnu.version..g
0x00000080 6e752e76 65727369 6f6e5f72 002e7265 nu.version_r..re
0x00000090 6c612e64 796e002e 72656c61 2e706c74 la.dyn..rela.plt
0x000000a0 002e696e 6974002e 706c742e 676f7400 ..init..plt.got.
0x000000b0 2e706c74 2e736563 002e7465 7874002e .plt.sec..text..
0x000000c0 66696e69 002e726f 64617461 002e6568 fini..rodata..eh
0x000000d0 5f667261 6d655f68 6472002e 65685f66 _frame_hdr..eh_f
0x000000e0 72616d65 002e696e 69745f61 72726179 rame..init_array
0x000000f0 002e6669 6e695f61 72726179 002e6479 ..fini_array..dy
0x00000100 6e616d69 63002e64 61746100 2e627373 namic..data..bss
0x00000110 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 app
Symbol table '.dynsym' contains 7 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTab
2: 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_registerTMCloneTable
6: 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 Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000318 0 SECTION LOCAL DEFAULT 1
2: 0000000000000338 0 SECTION LOCAL DEFAULT 2
3: 0000000000000358 0 SECTION LOCAL DEFAULT 3
4: 000000000000037c 0 SECTION LOCAL DEFAULT 4
5: 00000000000003a0 0 SECTION LOCAL DEFAULT 5
6: 00000000000003c8 0 SECTION LOCAL DEFAULT 6
7: 0000000000000470 0 SECTION LOCAL DEFAULT 7
8: 00000000000004f4 0 SECTION LOCAL DEFAULT 8
9: 0000000000000508 0 SECTION LOCAL DEFAULT 9
10: 0000000000000528 0 SECTION LOCAL DEFAULT 10
11: 0000000000000600 0 SECTION LOCAL DEFAULT 11
12: 0000000000001000 0 SECTION LOCAL DEFAULT 12
13: 0000000000001020 0 SECTION LOCAL DEFAULT 13
14: 0000000000001040 0 SECTION LOCAL DEFAULT 14
15: 0000000000001050 0 SECTION LOCAL DEFAULT 15
16: 0000000000001060 0 SECTION LOCAL DEFAULT 16
17: 0000000000001218 0 SECTION LOCAL DEFAULT 17
18: 0000000000002000 0 SECTION LOCAL DEFAULT 18
19: 000000000000201c 0 SECTION LOCAL DEFAULT 19
20: 0000000000002068 0 SECTION LOCAL DEFAULT 20
21: 0000000000003db8 0 SECTION LOCAL DEFAULT 21
22: 0000000000003dc0 0 SECTION LOCAL DEFAULT 22
23: 0000000000003dc8 0 SECTION LOCAL DEFAULT 23
24: 0000000000003fb8 0 SECTION LOCAL DEFAULT 24
25: 0000000000004000 0 SECTION LOCAL DEFAULT 25
26: 0000000000004018 0 SECTION LOCAL DEFAULT 26
27: 0000000000000000 0 SECTION LOCAL DEFAULT 27
28: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
29: 0000000000001090 0 FUNC LOCAL DEFAULT 16 deregister_tm_clones
30: 00000000000010c0 0 FUNC LOCAL DEFAULT 16 register_tm_clones
31: 0000000000001100 0 FUNC LOCAL DEFAULT 16 __do_global_dtors_aux
32: 0000000000004018 1 OBJECT LOCAL DEFAULT 26 completed.8060
33: 0000000000003dc0 0 OBJECT LOCAL DEFAULT 22 __do_global_dtors_aux_fin
34: 0000000000001140 0 FUNC LOCAL DEFAULT 16 frame_dummy
35: 0000000000003db8 0 OBJECT LOCAL DEFAULT 21 __frame_dummy_init_array_
36: 0000000000000000 0 FILE LOCAL DEFAULT ABS main.c
37: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
38: 000000000000218c 0 OBJECT LOCAL DEFAULT 20 __FRAME_END__
39: 0000000000000000 0 FILE LOCAL DEFAULT ABS
40: 0000000000003dc0 0 NOTYPE LOCAL DEFAULT 21 __init_array_end
41: 0000000000003dc8 0 OBJECT LOCAL DEFAULT 23 _DYNAMIC
42: 0000000000003db8 0 NOTYPE LOCAL DEFAULT 21 __init_array_start
43: 000000000000201c 0 NOTYPE LOCAL DEFAULT 19 __GNU_EH_FRAME_HDR
44: 0000000000003fb8 0 OBJECT LOCAL DEFAULT 24 _GLOBAL_OFFSET_TABLE_
45: 0000000000001000 0 FUNC LOCAL DEFAULT 12 _init
46: 0000000000001210 5 FUNC GLOBAL DEFAULT 16 __libc_csu_fini
47: 0000000000004010 8 OBJECT GLOBAL DEFAULT 25 my_name
48: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTab
49: 0000000000004000 0 NOTYPE WEAK DEFAULT 25 data_start
50: 0000000000004018 0 NOTYPE GLOBAL DEFAULT 25 _edata
51: 0000000000001218 0 FUNC GLOBAL HIDDEN 17 _fini
52: 0000000000000000 0 FUNC GLOBAL DEFAULT UND printf@@GLIBC_2.2.5
53: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@@GLIBC_
54: 0000000000004000 0 NOTYPE GLOBAL DEFAULT 25 __data_start
55: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
56: 0000000000004008 0 OBJECT GLOBAL HIDDEN 25 __dso_handle
57: 0000000000002000 4 OBJECT GLOBAL DEFAULT 18 _IO_stdin_used
58: 00000000000011a0 101 FUNC GLOBAL DEFAULT 16 __libc_csu_init
59: 0000000000004020 0 NOTYPE GLOBAL DEFAULT 26 _end
60: 0000000000001060 47 FUNC GLOBAL DEFAULT 16 _start
61: 0000000000004018 0 NOTYPE GLOBAL DEFAULT 26 __bss_start
62: 0000000000001174 30 FUNC GLOBAL DEFAULT 16 main
63: 0000000000001149 43 FUNC GLOBAL DEFAULT 16 say_hello
64: 0000000000004018 0 OBJECT GLOBAL HIDDEN 25 __TMC_END__
65: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
66: 0000000000000000 0 FUNC WEAK DEFAULT UND __cxa_finalize@@GLIBC_2.2在最后位置找到了亲切的老朋友 main和say_hello
62: 0000000000001174 30 FUNC GLOBAL DEFAULT 16 main
63: 0000000000001149 43 FUNC GLOBAL DEFAULT 16 say_hellomain函数符号对应的数值为0x1174，其类型为FUNC，大小为30字节，对应的代码区索引为16.say_hello函数符号对应数值为0x1149，其类型为FUNC，大小为43字节，对应的代码区索引同为16.
Section Header Table:
[16] .text PROGBITS 0000000000001060 00001060
00000000000001b5 0000000000000000 AX 0 0 16反汇编代码区
在理解了String Table和Symbol Table的作用后，通过objdump反汇编来理解一下.text代码区:
root@5e3abe332c5a:/home/docker/case_code_100# objdump -j .text -l -C -S app
0000000000001149 <say_hello>:
say_hello():
1149: f3 0f 1e fa endbr64
114d: 55 push %rbp
114e: 48 89 e5 mov %rsp，%rbp
1151: 48 83 ec 10 sub $0x10，%rsp
1155: 48 89 7d f8 mov %rdi，-0x8(%rbp)
1159: 48 8b 45 f8 mov -0x8(%rbp)，%rax
115d: 48 89 c6 mov %rax，%rsi
1160: 48 8d 3d 9d 0e 00 00 lea 0xe9d(%rip)，%rdi # 2004 <_IO_stdin_used+0x4>
1167: b8 00 00 00 00 mov $0x0，%eax
116c: e8 df fe ff ff callq 1050 <printf@plt>
1171: 90 nop
1172: c9 leaveq
1173: c3 retq
0000000000001174 <main>:
main():
1174: f3 0f 1e fa endbr64
1178: 55 push %rbp
1179: 48 89 e5 mov %rsp，%rbp
117c: 48 8b 05 8d 2e 00 00 mov 0x2e8d(%rip)，%rax # 4010 <my_name>
1183: 48 89 c7 mov %rax，%rdi
1186: e8 be ff ff ff callq 1149 <say_hello>
118b: b8 00 00 00 00 mov $0x0，%eax
1190: 5d pop %rbp
1191: c3 retq
1192: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax，%rax，1)
1199: 00 00 00
119c: 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 00001060
00000000000001b5 0000000000000000 AX 0 0 16难度main不是入口地址? 那0x1060上放的是何方神圣，再查符号表发现是
60: 0000000000001060 47 FUNC GLOBAL DEFAULT 16 _start从反汇编堆中找到 _start
0000000000001060 <_start>:
_start():
1060: f3 0f 1e fa endbr64
1064: 31 ed xor %ebp，%ebp
1066: 49 89 d1 mov %rdx，%r9
1069: 5e pop %rsi
106a: 48 89 e2 mov %rsp，%rdx
106d: 48 83 e4 f0 and $0xfffffffffffffff0，%rsp
1071: 50 push %rax
1072: 54 push %rsp
1073: 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 hlt
108f: 90 nop这才看到了0x1174的main函数.所以真正的说法是:
- 从内核动态加载的视角看，程序运行首个函数并不是
main，而是_start. - 但从应用程序开发者视角看，
main就是启动函数.
经常有很多小伙伴抱怨说：不知道学习鸿蒙开发哪些技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？
为了能够帮助到大家能够有规划的学习，这里特别整理了一套纯血版鸿蒙（HarmonyOS Next）全栈开发技术的学习路线，包含了鸿蒙开发必掌握的核心知识要点，内容有（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、WebGL、元服务、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony驱动开发、系统定制移植等等）鸿蒙（HarmonyOS NEXT）技术知识点。
《鸿蒙 (Harmony OS)开发学习手册》（共计892页）
如何快速入门？
1.基本概念
2.构建第一个ArkTS应用
3.……
开发基础知识:
1.应用基础知识
2.配置文件
3.应用数据管理
4.应用安全管理
5.应用隐私保护
6.三方应用调用管控机制
7.资源分类与访问
8.学习ArkTS语言
9.……
基于ArkTS 开发
1.Ability开发
2.UI开发
3.公共事件与通知
4.窗口管理
5.媒体
6.安全
7.网络与链接
8.电话服务
9.数据管理
10.后台任务(Background Task)管理
11.设备管理
12.设备使用信息统计
13.DFX
14.国际化开发
15.折叠屏系列
16.……
鸿蒙开发面试真题（含参考答案）
OpenHarmony 开发环境搭建
《OpenHarmony源码解析》
- 搭建开发环境
- Windows 开发环境的搭建
- Ubuntu 开发环境搭建
- Linux 与 Windows 之间的文件共享
- ……
- 系统架构分析
- 构建子系统
- 启动流程
- 子系统
- 分布式任务调度子系统
- 分布式通信子系统
- 驱动子系统
- ……
OpenHarmony 设备开发学习手册
写在最后
如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：
- 点赞，转发，有你们的 『点赞和评论』，才是我创造的动力。
- 关注小编，同时可以期待后续文章ing🚀，不定期分享原创知识。
