当我们设置了 Enable Bitcode=YES ，进行Archive时，bitcode会被嵌入到链接后的Mach-O中，用于提交到App Store。从编译日志中可以看出，Archive时多了一个编译参数 -fembed-bitcode 。

非Archive编译时，Enable Bitcode 将会增加编译参数 -fembed-bitcode-marker， 该参数用于在Mach-O中做标记，但是不会真正产生Bitcode。因为本地编译调试时并不需要bitcode，去掉这个不必要的步骤加快编译速度。

对于静态库等打开了Bitcode编译，通过MachOview查看会发现有一个__LLVM, __bitcode 段；而全工程编译出来对应的是 __LLVM, __bundle 段；可以使用 segedit 命令将指定的Section导出：

    segedit XXX.o -extract __LLVM __bitcode result.bc

viewBundle.png

如上图，需要注意的是， __LLVM, __bundle导出的并不是直接的bitcode格式，通过MachOView查看可得知是Xar文档格式，xar格式包含了一个xml格式的文件头(TOC)，里面用于存放各种文件的基本属性以及一些附加附加信息，可以通过xar命令查看并解压

xar -d toc.xml -f bundle # 导出文件头

查看xml的结构，包括以下内容：

• ld 的基本参数，我们链接时使用的是clang，实际上clang内部调用了ld，这里记录的是ld的参数
  • version: bitcode bundle 的版本号
  • architecture: 目标架构
  • platform: 目标平台
  • sdkversion: sdk版本
  • dylibs: 链接的动态库
  • link-options: 其他链接参数
• 文件目录
  • checksum类型
  • 创建时间
  • 每个文件的信息
    • 文件名，这里并非原始文件名，而是按照链接时输入的顺序被重命名为数字序号
    • 基本属性，包括checksum、偏移、大小等
    • 文件类型，一般是Bitcode，还有两种特殊类型，Object以及Bundle，这里卖个关子，大家有兴趣可已自行研究(想想如果一个源代码文件是.s格式，要如何支持bitcode)
    • 编译器类型(clang/swift)及编译参数，这部分就是object文件中 __LLVM,__cmdline 的内容
  • 下一个文件的信息(如有)
  • 重复

如要提取bitcode，需要进一步解压：

xar -xf result.bc

通过otool检查二进制文件是否开启了bitcode：

otool -arch armv7 -l xxxx.a | grep __LLVM | wc -l 

通过判断是否包含 __LLVM 来判断是否支持bitcode，但是这种方式区分不了bitcode和bitcode-marker，确定是否包含bitcode，还需要检查otool输出中__LLVM Segment 的长度，如果长度只有1个字节，则并不能代表真正开启了bitcode：

$ otool -l test_bitcode.o | grep -A 2  __LLVM | grep size      
    size 0x0000000000000b10      
    size 0x0000000000000042 
$ otool -l test_bitcode_marker.o | grep -A 2  __LLVM | grep size      
    size 0x0000000000000001      
    size 0x0000000000000001

另外，Archive版本引入了 Symbol Hiding 和 Debug info Striping 机制，在链接时，bitcode中所有非导出符号均被隐藏，取而代之的是 __hidden#0_ 或者 __ir_hidden#1_ 这样的形式，debug信息也只保留了line-table，所有跟文件路径、标识符、导出符号等相关的信息全部都从bitcode中移除，相当于做了一层混淆，这种情况从IR代码中打印出的方法名全为__hidden#XXX，目前在尝试从中拿到内存地址再到符号表中去找映射关系。

符号表其实是DWARF的集合形式，它是内存地址与函数名，文件名，行号的映射表。DWARF 全名是 Debugging with Attribute Record Formats ，是一种调试信息的存放格式。

DWARF 第一版发布于 1992 年，主要是为 UNIX 下的调试器提供必要的调试信息，例如内存地址对应的文件名以及代码行号等信息，通常用于源码级别调试使用。另外通过 DWARF，还能还原运行时的地址成为可读的源码符号（及行号）。

DWARF 调试信息简单的来说就是在机器码和对应的源代码之间建立一座桥梁，大大提高了调试程序的能力。

iOS 中引入 DWARF 这种调试信息格式，其实也是顺应历史的潮流，因为 DWARF 已经在类 UNIX 系统中逐步替换 stabs（symbol table strings），成为一种主流的调试信息格式。使用 GCC 或者 LLVM 系列编译器都可以很方便的生成 DWARF 调试信息。

知道了Bitcode在Mach-O的位置以及获取方法，再来看看Mach-O的其他内容，Mach-O 其实是 Mach Object 文件格式的缩写。

属于 Mach-O 格式的常见文件

• 目标文件 .o
• 库文件
  • .a
  • .dylib
  • Framework
• 可执行文件
• dyld ( 动态链接器 )
• .dsym ( 符号表 )

使用 file 命令可以查看文件类型

一张网上到处都有的结构图：

mach-o.png

1. Header

描述了 Mach-O 的 CPU 架构、文件类型以及加载命令等信息。

可进入 Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/mach-o/loader.h 查看头文件

struct mach_header_64 {
    uint32_t    magic;      /* 魔数 0xfeedface、0xcafebabe、0xfeedfacf 分别对应64、fat、64*/
    //如0xfeedface表示32位二进制格式，0xfeedfacf表示64位；
    cpu_type_t  cputype;    /* cpu 类型 比如 ARM */
    cpu_subtype_t   cpusubtype; /* cpu 具体类型 比如arm64 , armv7 */
    uint32_t    filetype;   /* 文件类型 例如可执行文件 .. 具体见下面枚举 */
    uint32_t    ncmds;      /* load commands 加载命令条数 */
    uint32_t    sizeofcmds; /* load commands 加载命令大小*/
    uint32_t    flags;      /* 标志位标识二进制文件支持的功能 , 主要是和系统加载、链接有关  具体见下面枚举*/
    uint32_t    reserved;   /* reserved , 保留字段 */
};

filetype：
#define    MH_OBJECT    0x1        /* Target 文件：编译器对源码编译后得到的中间结果 */
#define    MH_EXECUTE    0x2        /* 可执行二进制文件 */
#define    MH_FVMLIB    0x3        /* VM 共享库文件 */
#define    MH_CORE        0x4        /* Core 文件，一般在 App Crash 产生 */
#define    MH_PRELOAD    0x5        /* preloaded executable file */
#define    MH_DYLIB    0x6        /* 动态库 */
#define    MH_DYLINKER    0x7        /* 动态连接器 /usr/lib/dyld */
#define    MH_BUNDLE    0x8        /* 非独立的二进制文件，往往通过 gcc-bundle 生成 */
#define    MH_DYLIB_STUB    0x9        /* 静态链接文件 */
#define    MH_DSYM        0xa        /* 符号文件以及调试信息，在解析堆栈符号中常用 */
#define    MH_KEXT_BUNDLE    0xb        /* x86_64 内核扩展 */

flags：
#define    MH_NOUNDEFS    0x1        /* Target 文件中没有带未定义的符号，常为静态二进制文件 */
#define MH_INCRLINK 0x2     /* the object file is the output of an
                       incremental link against a base file
                       and can't be link edited again */
#define MH_DYLDLINK 0x4     /* the object file is input for the
                       dynamic linker and can't be staticly
                       link edited again */
#define MH_BINDATLOAD   0x8     /* the object file's undefined
                       references are bound by the dynamic
                       linker when loaded. */
#define MH_PREBOUND 0x10        /* the file has its dynamic undefined
                       references prebound. */
#define MH_SPLIT_SEGS    0x20  /* Target 文件中的只读 Segment 和可读写 Segment 分开  */
#define MH_TWOLEVEL    0x80        /* 该 Image 使用二级命名空间(two name space binding)绑定方案 */
#define MH_FORCE_FLAT    0x100 /* 使用扁平命名空间(flat name space binding)绑定（与 MH_TWOLEVEL 互斥） */
#define MH_WEAK_DEFINES    0x8000 /* 二进制文件使用了弱符号 */
#define MH_BINDS_TO_WEAK 0x10000 /* 二进制文件链接了弱符号 */
#define MH_ALLOW_STACK_EXECUTION 0x20000/* 允许 Stack 可执行 */
#define    MH_PIE 0x200000  /* 对可执行的文件类型启用地址空间 layout 随机化 */
#define MH_NO_HEAP_EXECUTION 0x1000000 /* 将 Heap 标记为不可执行，可防止 heap spray 攻击 */

2. Load Commands

描述了文件中数据的具体组织结构，不同的数据类型使用不同的加载命令表示。

Load Commands 详细保存着加载指令的内容 , 告诉链接器如何去加载这个 Mach-O 文件.

通过查看内存地址我们发现 , 在内存中 , Load Commands 是紧跟在 Mach_header 之后的 .

3. Data

每一个段（Segment）的数据都保存在其中，段的概念和 ELF 文件中段的概念类似，都拥有一个或多个 Section ，用来存放数据和代码。

Segment:
#define    SEG_PAGEZERO    "__PAGEZERO" /* 当时 MH_EXECUTE 文件时，捕获到空指针 */
#define    SEG_TEXT    "__TEXT" /* 代码/只读数据段 */
#define    SEG_DATA    "__DATA" /* 数据段 */
#define SECT_DATA   "__data"    /* the real initialized data section */
                    /* no padding, no bss overlap */
#define SECT_BSS    "__bss"     /* the real uninitialized data section*/
                    /* no padding */
#define SECT_COMMON "__common"  /* the section common symbols are */
                    /* allocated in by the link editor */
#define    SEG_OBJC    "__OBJC" /* Objective-C runtime 段 */
#define SECT_OBJC_SYMBOLS "__symbol_table"  /* symbol table */
#define SECT_OBJC_MODULES "__module_info"   /* module information */
#define SECT_OBJC_STRINGS "__selector_strs" /* string table */
#define SECT_OBJC_REFS "__selector_refs"    /* string table */

#define SEG_ICON     "__ICON"   /* the icon segment */
#define SECT_ICON_HEADER "__header" /* the icon headers */
#define SECT_ICON_TIFF   "__tiff"   /* the icons in tiff format */
#define    SEG_LINKEDIT    "__LINKEDIT" /* 包含需要被动态链接器使用的符号和其他表，包括符号表、字符串表等 */

Segment数据结构:
struct segment_command_64 { 
    uint32_t    cmd;        /* LC_SEGMENT_64 */
    uint32_t    cmdsize;    /* section_64 结构体所需要的空间 */
    char        segname[16];    /* segment 名字，上述宏中的定义 */
    uint64_t    vmaddr;        /* 所描述段的虚拟内存地址 */
    uint64_t    vmsize;        /* 为当前段分配的虚拟内存大小 */
    uint64_t    fileoff;    /* 当前段在文件中的偏移量 */
    uint64_t    filesize;    /* 当前段在文件中占用的字节 */
    vm_prot_t    maxprot;    /* 段所在页所需要的最高内存保护，用八进制表示 */
    vm_prot_t    initprot;    /* 段所在页原始内存保护 */
    uint32_t    nsects;        /* 段中 Section 数量 */
    uint32_t    flags;        /* 标识符 */
};

Section数据结构:
struct section_64 { 
    char        sectname[16];    /* Section 名字 */
    char        segname[16];    /* Section 所在的 Segment 名称 */
    uint64_t    addr;        /* Section 所在的内存地址 */
    uint64_t    size;        /* Section 的大小 */
    uint32_t    offset;        /* Section 所在的文件偏移 */
    uint32_t    align;        /* Section 的内存对齐边界 (2 的次幂) */
    uint32_t    reloff;        /* 重定位信息的文件偏移 */
    uint32_t    nreloc;        /* 重定位条目的数目 */
    uint32_t    flags;        /* 标志属性 */
    uint32_t    reserved1;    /* 保留字段1 (for offset or index) */
    uint32_t    reserved2;    /* 保留字段2 (for count or sizeof) */
    uint32_t    reserved3;    /* 保留字段3 */
};

部分的 Segment （主要指的 __TEXT 和 __DATA）可以进一步分解为 Section。之所以按照 Segment -> Section 的结构组织方式，是因为在同一个 Segment 下的 Section，可以控制相同的权限，也可以不完全按照 Page 的大小进行内存对其，节省内存的空间。而 Segment 对外整体暴露，在程序载入阶段映射成一个完整的虚拟内存，更好的做到内存对齐。

下面列举一些常见的 Section。

ASLR

Bitcode的工作流程及安全性评估