第3砍 - 不亮也光

烦恼着要开始上班了

菜鸟人生 Start?[Y/N]

> N

今天还没进入正题

因为我们需要先简单了解编译流程

这样才知道为什麽昨天的执行档没有拔掉symbol

到底编译器做了哪些事, 实际上分成哪几个stage

我们写好一个C code, 丢给compiler

现在的编译器都会直接做好每个流程, 所以其实可以每个阶段分开做.

之前在LLVM写过简单的Pass, 目的就是在C code产出asm code之後可以经过我们自己的Pass来做优化

首先我们先看整个流程图

reference: 图片来源

1. C code -> ASM

我们写的C code一定会include到header档, 除非是人中之龙. 什麽code都要自己手刻才完美的例外.

这里会经过Preprocessor, 目的是处理包含巨集(define)的扩展, 包含include哪些. 再丢给compiler把需要的档案编译成asm code(.s file)

$ gcc --help
...
  -S                       Compile only; do not assemble or link
  

$ gcc -S hello.c
$ file hello.s
hello.s: assembler source, ASCII text

在这步骤我们可以使用-S flag单纯编译C code->ASM 而不会进行组译和link

2. ASM code -> object file & linking

刚刚我们产生了一个asm file, 稍微看看内容可以看到很像挖到古埃及文物一样的文字

接下来我们会把这个档案喂给assembler进行组译成object file;

$ gcc -c hello.s
$ file hello.o
hello.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

如果执行档或专案很大就会有很多的object file要linking

假设我们自己有一个main()的hello.o 跟一个类似handler形式的world.o

$ gcc -o hello_world hello.o world.o
$ file hello_world
hello_world: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d7706b2b9613194ec27473ff5b772d770d0058fe, not stripped

可以看一下main跟lib两个function都被并在同一个执行档上

另外一个点是我们产出来的ELF file没有经过strip, 所以我们还可以从symbol table抓一些资讯, 不管是debugger用还是其他静态工具, 一旦经过strip之後就会很难判读与追踪代码

3. 执行

执行档一般只会躺在档案系统上, 如果没有执行与载入, 他就只是二进制文件而不会是程序.
执行时会由loader加载, 查找每一个section到对应的记忆体位址上, 需要重定位的摆好之後回填正确的位址, 函式库则会依据是否为动态连结的优化方式, 若为动态连结则会找到已经躺在记忆体上的共享函式库并且回填已知的位址

参考图片:

谢谢大家
已经被月饼砸到咪咪猫猫还活下来的我