0
点赞
收藏
分享

微信扫一扫

编译与链接过程的思考

前言

最近遇到一个错误,如下


在解决过程中,回顾了很多知识,于是有了这篇文章。
关键词:预处理、编译、汇编、链接、动态链接库、静态链接库、真机调试

正文

以.c文件的编译流程为例,如下图。
我们按照以下的步骤,用gcc对代码进行编译。



test.c的代码如下

#include <stdio.h>
int main()
{
    puts("It's OK.");
    return 0;
}

gcc指令处理

  • 预处理
gcc -E test.c -o test.i
  • 编译
gcc -S test.i -o test.s
  • 汇编
gcc -c test.s -o test.o
  • 链接
gcc test.o -o test

静态连接与动态链接

1、静态链接

静态连接就是把静态连接库(.a文件)中的文件链接到可执行文件中;

2、动态链接

动态链接就是仅在可执行文件中加入相关描述文件,执行时再动态加载相应的动态链接库;

3、链接过程

链接的过程,也就是符号重定位
c/c++ 程序的编译是以文件为单位进行的,因此每个 c/cpp 文件也叫作一个编译单元(translation unit), 源文件先是被编译成一个个目标文件, 再由链接器把这些目标文件组合成一个可执行文件或库,链接的过程,其核心工作是解决模块间各种符号(变量,函数)相互引用的问题,对符号的引用本质是对其在内存中具体地址的引用,因此确定符号地址是编译,链接,加载过程中一项不可缺少的工作,这就是所谓的符号重定位。本质上来说,符号重定位要解决的是当前编译单元如何访问「外部」符号这个问题。

iOS相关

下图是我们Xcode工程的设置,我们来一一解析。


Embedded Binaries

  • GPUImage.framework
  • lib.framework

这两个是动态库,framework的内容格式如下


Linked Frameworks and Libraries

  • libstdc++.6.tbd
    tbd是dylib的优化版本
  • libXG-SDK.a
    信鸽推送的静态链接库
  • lib*.framework、GPUImage.framework
    直播的framework和GPUImage
  • libPods-Live.a
    CocoaPods管理并生成的静态链接库

了解完工程的基本设置后,我们来定位前面提到的问题。
进行的操作是Archive -> Export -> Ad Hoc,提示的错误信息是
Found an unexpected Mach-O header code.
点击show logs,然后选择standard.log


log的描述是did not contain a "archived-expanded-entitlements.xcent" resource

检查工程的设置,发现是同事把一个静态库放到了Embedded Binaries项里面,然而静态库是不能打包到ipa里面。(静态库里的代码会编译链接到可执行文件,资源文件需要重新打包成一个bundle文件放入ipa包)

动态库、静态库的制作

简书已经有非常详细的教程,介绍静态库和动态库的制作。

Debug调试

上架AppStore的应用,在Xcode就可以查看线上的crash信息。
但有时候,真机调试的出现闪退,我们通过Xcode读取真机的crash日志,发现日志是这样的:



提供的是,crash时候的地址信息。
我们知道,编译时期函数的地址就已经确定,那么根据地址信息应该是能定位到函数。

APPLE的官网介绍了一个指令:

// 记得把live改成你对应的包名
atos -o live.app/live -arch arm64 0x1000d51c0 -l 0x100064000

打开安装到真机的.app文件夹,按照上面的格式输入crash时候的地址信息即可。
如果发现出来的是一个毫不相关的函数,用dwarfdump --uuid live.app/live 指令确定下Binary Images是否和crash一致。

总结

在写文章过程中,简单复习了下编译原理与汇编语言,深感程序员的技能树太过庞大,随便一个分支就够学习一辈子。
平时开发遇到问题,习惯性的刨根问底,这次简单把这些知识串联起来,并和工程作相应结合,加深记忆。
文章如有疏漏,敬请指出。

引用

  • 《程序员的自我修养—链接、装载与库》
  • C程序编译过程浅析
举报

相关推荐

0 条评论