叙述 C语言编译

@(C语言)[code]

用一段简单的代码,探讨下从C代码到最终可执行文件的编译过程,追根究底。 偶尔了解下底层,也就没那么多莫名其妙了。

工作原因有时候会用python写写测试工具,感受到其快速实现应用的便利,但由于偏底层开发,主力语言依然是C。对于开发语言没有什么优劣概念,在特定的情景下哪种实现更佳就用哪种,工具合适才是最好的。

个人开发环境 ubuntu 14.04


编译的作用

相比python,lua等脚本语言解释执行方式,编译C是为了提高程序的运行效率。把对用户友好的语言文本编译成对机器友好的特定指令直接执行,而不是执行时一条一条通过解释器解析执行,很大地提高了执行的效率。对应C主要用于底层,系统层次,追求高性能表现,亦或者,平台资源限制。

编译的过程

gcc 的编译流程分为四个步骤: 计算机系统设计基本原则:层次化和抽象。

编译flow

编写一个最简单的程序 hello.c,以此为例,看看各个过程做了什么事情。

#include<stdio.h>

#define NUM(x) ((x) + 1)
int main(void)
{
    printf("Hello world %d\\\\r\\\\n", NUM(1));
    return 0;
}

预处理(Pre-Processing)

预处理主要完成的工作:

  • 根据#if后面的条件决定需要编译的代码
  • 将源文件中#include格式包含的文件直接复制到编译的源文件中
  • 用实际值替换用#define定义的字符串

对源代码进行预处理操作

$ gcc -E hello.c -o hello.i

使用编辑器打开输出hello.i,一看吓一跳,原本7、8的代码变成800多行 截取开头结尾如下

# 1 "hello.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
...
...
int main(void)
{
 printf("Hello world %d\\\\r\\\\n", ((1) + 1));
 return 0;
}

我打开文件 stdio.h 对比发现,hello.i 文件开头多出来的一大堆东西,就是stdio.h 经过#if条件选择后留下的(包括其他包含文件的展开,同理)。同时在最下面看到熟悉的printf函数中定义的宏被直接替换成对应的文本。 在这里提出两个问题

  • 预处理宏展开可能陷入死循环? 我修改了了代码, 宏里面调用了自己,并且没有递归退出条件
#include<stdio.h>

#define NUM(x) (NUM(x) + 1)
int main(void)
{
    printf("Hello world %d\\\\r\\\\n", NUM(1));
    return 0;
}

输出hello.i可以看到,宏展开遇到自己就会停止,避免陷入死循环

int main(void)
{
 printf("Hello world %d\\\\r\\\\n", (NUM(1) + 1));
 return 0;
}
  • include 包含头文件重复?

预处理会直接把对应的头问题展开,如果包含的头文件本身包含了自己,是否也会陷入死循环? 简单编写文件测试

inc.h 文件

#include "inc.h"

inc.c 文件

#include "inc.h"

int main(void)
{
    return 0;
}

预处理结果出错,提示如下:

inc.h:1:17: error: #include nested too deeply
 #include "inc.h"

说明对于文件的展开是可能出现重复,递归的,也说明了为什么在每个被包含的头文件,需要添加如下代码段。

#ifndef _XXX__XXX
#define _XXX_XXX

#endif

编译(Compiling)

这一环节,是把C代码转换为汇编代码并根据需求进行一定程度的优化处理。 执行命令进行编译

$ gcc -S hello.i -o hello.s
# gcc -S 实际调用cc1,所以也可以直接使用cc1编译

生成hello.s (AT&T 格式) 这代码初看起来晦涩难懂,再细细看起来,还是很难懂。

    .file   "hello.c"
    .section    .rodata
.LC0:
    .string "Hello world %d\\\\r\\\\n"
    .text
    .globl  main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    
    movl    $2, %esi  # 编译器直接替换为宏 NUM(1) 的结果
    movl    $.LC0, %edi # 设置字符串保存的地址
    movl    $0, %eax
    call    printf    
    #  调用printf子例程,只有一个参数的printf gcc
    #  会把它替换成_puts提高效率, 加-fno-builtin 取消
    
    movl    $0, %eax  # main return 0
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4"
    .section    .note.GNU-stack,"",@progbits

编译器的优化

编译会有一个中间过程,进行优化(前端)后再最终输出汇编代码(后端), gcc 可以通过以下命令查看, 感觉不是给人类看的。

$ gcc -S -fdump-rtl-expand hello.c

使用clang(<-编译器)也可以查看输出中间过程:

$ clang-3.5 -S -emit-llvm hello.c

clang 输出的可读性更强,可以大概看出程序的面貌(因为这个程序很简单...)

; ModuleID = 'hello.c'
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"

@.str = private unnamed_addr constant [17 x i8] c"Hello world %d\\\\0D\\\\0A\\\\00", align 1

; Function Attrs: nounwind uwtable
define i32 @main() #0 {
  %1 = alloca i32, align 4
  store i32 0, i32* %1
  %2 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([17 x i8]* @.str, i32 0, i32 0), i32 2)
  ret i32 0
}

declare i32 @printf(i8*, ...) #1

attributes #0 = { nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }

!llvm.ident = !{!0}

!0 = metadata !{metadata !"Ubuntu clang version 3.5.0-4ubuntu2~trusty2 (tags/RELEASE_350/final) (based on LLVM 3.5.0)"}

我尝试在hello.c 的源代码中添加一个无用的循环

for (int i = 0; i < 10; ++i) {
    i = i;    
}

然后分别用以下两个条命令编译,查看输出中间文件.ll (使用clang是因为输出结果比较适合阅读)

# 默认不优化处理 -O0
$ clang-3.5 -S -emit-llvm hello.c
# 开启代码优化
$ clang-3.5 -O3 -S -emit-llvm hello.c

第一种不优化情况下,编译器老老实实把我写的"没啥作用"的代码原原本本的编译出来. 第二种进行了优化, 那段代码不见了...... 我想起工作上遇到的,使用for 进行简单延时匹配一些硬件操作的时序,悲剧了. (输出结果我就不贴上来了。)

中间层优化是和体系代码无关的情况下进行的,优化后再调用对应体系的后端生成汇编代码。 M中体系都可以共用中间层优化,而不是M中体系重新实现M中优化。

汇编(Assembling)

这一步骤相对简单,将汇编代码转换为对应的机器执行指令,由于这一步丢失的信息很少,所以可以通过反汇编把机器码还原为汇编代码,但是再进一步还原到高级语言就不可能了。

$ gcc -c hello.s -o hello.o
# 可以直接调用汇编器 as
$ as hello.s -o hello.o。

使用objdump对生成的ELF进行反汇编

$ objdump  -S hello.o

hello.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <main>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   be 02 00 00 00          mov    $0x2,%esi
   9:   bf 00 00 00 00          mov    $0x0,%edi
   e:   b8 00 00 00 00          mov    $0x0,%eax
  13:   e8 00 00 00 00          callq  18 <main+0x18> # 看这里
  18:   b8 00 00 00 00          mov    $0x0,%eax
  1d:   5d                      pop    %rbp
  1e:   c3                      retq   

看到 13行, 原本call printf 的那句被替换为一个跳转,而且跳转到下一条指令。因为printf是一个外部调用,这个地址需要下一步链接的时候才能确定,这时候只是一个占位。

链接(Linking)

主要是在不同模块间对符号进行重定位

在ELF文件 hello.o 里保存一张重定位表(relocation table),保存了其他地方的函数、变量(统称符号)的名字和地址。 可以通过readelf读取出来

$ readelf --relocs hello.o

Relocation section '.rela.text' at offset 0x5a0 contains 2 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000000000a  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
000000000014  000a00000002 R_X86_64_PC32     0000000000000000 printf - 4

Relocation section '.rela.eh_frame' at offset 0x5d0 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000020  000200000002 R_X86_64_PC32     0000000000000000 .text + 0

可以看到,汇编后, printf的地址还是空的,没有填写上对应的地址。

使用nm可以查看文件的符号定义, 可以看到 "U", 表示该符号未定义。

$ nm hello.o
0000000000000000 T main
                 U printf

printf 是在lib.a库(由多个.O文件打包就成了.a库)里面实现所,所以查看下里面的定义,可以看到具体是到printf.o这个文件。

$ objdump  -t /usr/lib/x86_64-linux-gnu/libc.a | grep "printf"
...
printf.o:     file format elf64-x86-64
0000000000000000 g     F .text  000000000000009e __printf
0000000000000000         *UND*  0000000000000000 vfprintf
0000000000000000 g     F .text  000000000000009e printf
...

而当我手动尝试链接的时候,又被提示一堆未定义,而这些工作gcc会自动递归查找去解决。

$ gcc -static hello.c
$ ./a.out 
Hello world 2
$ du -h a.out 
856K    a.out
$ nm a.out  | grep " printf"
0000000000407ea0 T printf

编译后执行,发现一切正常,printf已经定义了,但是一个简单的程序竟然是856K....

$ gcc hello.c
$ ./a.out 
Hello world 2
$ du -h a.out 
12K a.out
$ nm a.out  | grep " printf"
                 U printf@@GLIBC_2.2.5

采用动态加载的模式编译,应用体积减小了很多,但是看到printf提示未定义,标记改了,表示是一个动态链接。 通过file也可以查看执行文件是否动态链接 dynamically linked 和 statically linked

$ gcc hello.c
$ file a.out 
a.out: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=8bdbcefb6289597b2123017d2678b11a6f742f23, not stripped
$ gcc -static hello.c
$ file a.out 
a.out: ELF 64-bit LSB  executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=25ff17d24016dd4a453a5ac53e3a3fee0f00a5ec, not stripped

这就是动态链接库的好处了,把共用的代码加载到系统,每个程序需要用到时候直接调用,而不需要都包含到每个可执行文件中,减少开销。在执行的时候,通过加载器获取实际地址执行。

其实动态链接库是不知道自己会被加载到内存哪个位置的,所以对于这个种链接,程序在执行的时候,才能获取到实际的地址,涉及到GOT和PLI。 GOT中的信息需要在动态链接库被程序加载后立刻填写正确。这就给采用动态链接库的程序在启动时带来了一定额外开销,从而减缓了启动速度。ELF采用了做延迟绑定的做法来解决这一问题。基本思想就是通过增加另外一个间接层,使得函数第一次被用到时才进行绑定,这就是PLT(Procedure Linkage Table)的作用。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏技术小讲堂

WCF中操作的分界于调用顺序和会话的释放操作分界实例停止

操作分界 在WCF操作契约的设计中,有时会有一些调用顺序的业务,有的操作不能最先调用,有的操作必须最后调用,比如在从一个箱子里拿出一件东西的时候,必须先要执行打...

3356
来自专栏企鹅号快讯

UNIX 高手的 10 个习惯

Unix运维工程师看过来:10个能够提高您的 UNIX 命令行效率的好习惯——并在此过程中摆脱不良的使用模式。本文循序渐进地指导您学习几项用于命令行操作的技术,...

1929
来自专栏CSDN技术头条

Java 9的14个新特性总结

Java 9 包含了丰富的特性集。虽然Java 9没有新的语言概念,但是有开发者感兴趣的新的API和诊断命令。 我们将快速的,着重的浏览其中的几个新特性: ? ...

2135
来自专栏数据结构笔记

实战:异步爬取之异步的简单使用

首先,对于少量的请求(几百)我们不推荐使用异步,一般是成千上万的请求我们才使用异步,比如说爬取全站。

1352
来自专栏友弟技术工作室

vim精简版教程

vim编辑器 ? vim trree 编辑器的分类 文本编辑器,ASCII码 字处理器:word 全称 vi:Visual interface vim: Vis...

2285
来自专栏大史住在大前端

webpack4.0各个击破(7)—— plugin篇

plugin机制是webpack中另一个核心概念,它基于事件流框架tapable,你可以参考浏览器环境中的【DOM事件模型】,【SPA模型中的生命周期钩子】或是...

1542
来自专栏贾老师の博客

【笔记】ejoy2d —— spritepack

952
来自专栏欧阳大哥的轮子

从Xcode10不再支持libstdc++说起

众所周知从Xcode10起,苹果摒弃了对libstdc++库的支持转而支持libc++库了。这两个库在Xcode9甚至更早的版本就已经同时存在于系统中并且可供开...

3113
来自专栏烙馅饼喽的技术分享

用ECMAScript4 ( ActionScript3) 实现Unity的热更新 -- Demo分析

如何创建工程 下载最新的Unity发布插件包。 打开Unity,新建一个项目 将插件包导入 ? 在菜单中点击ASRuntime/Create ActionScr...

34110
来自专栏Java帮帮-微信公众号-技术文章全总结

【大牛经验】Java9的新特性

Java 9 包含了丰富的特性集。虽然Java 9没有新的语言概念,但是有开发者感兴趣的新的API和诊断命令。 我们将快速的,着重的浏览其中的几个新特性: ? ...

3628

扫码关注云+社区

领取腾讯云代金券