gcc源码编译xgcc-C语言生成可执行文件的过程

也想出现在这里？点击联系我~

立即下单

进入商城

进不了网站？换个网络试试！

明天我将使用gcc编译器为大家演示C语言的编译过程。

首先，我们将粘贴我们朴素的源代码

1.预编译过程

由.c-->.o文件生成

通过gcc-Emain.c-omain.i执行c语言的预编译过程，生成main.o文件

我们怀着崇敬的心情看看生成的main.o文件是什么样子的

（由于篇幅原因gcc源码编译xgcc，里面的截图只展示了原文件的十分之几的代码）

可以发现最下面的部分是我们的源码，也就是main函数。 那么，main函数中的几千行代码到底是什么呢？

虽然，那是我们的#include，这就是我们定义的宏扩展的样子

别小看这个文件gcc源码编译xgcc，可以直接运行

有侦探的话可以发现我里面的main函数有一句错误

我的主要功能是这样的

 int int mian(){
	printf(".....");
	return 0
 }
1234

聪明人能得出什么推论？

预编译过程中不会进行句型检测，我们定义的宏只会简单展开

编译

从 .i 文件生成 .s 汇编文件

gcc-smain.i-omain.s

这一步，我迅速偷偷的修正了句型，因为句型检测（虽然不可避免，但是因为句型错误怎么可能编译成正确的汇编代码呢）

这个汇编文件，包括我们下一步要生成的目标文件，是无法直接运行的，因为对它的函数调用都是符号引用，此时我们并不知道它的真实文件地址在哪里。

生成目标文件

gcc-cmain.s-omain.o

我们使用file命令查看目标文件

发现这个文件是Mach-O类型，哪些是Mach-O？

虽然macos具有unix的很多特性，并且没有采用unix上可执行文件的elf(excutablelinkformat)格式，但是它使用Mach-O作为其可执行文件格式，哦，所以看起来是mac平台上的可执行文件，类似于unix的elf和win的PE

不过，目前尚未链接。 例如，它仍然没有我们main函数中引用的printf的真实内存地址，因此它不是一个真正的可执行文件。

生成可执行文件

兴奋的。 。 .终于到了最后一步

gcc-vmain.o-omain 生成我们的可执行文件

我们双击这个文件，可以发现这个文件可以正常运行，是不是第四天的第一天比较特殊呢？