Mach-O格式、进程以及线程内幕（一）

可执行文件

    说到可执行文件，就不能不说到进程，进程是特殊文件在内存中加载得到的结果，那么一个进程运行，肯定是操作系统能够理解的文件格式，这样操作系统才能解析文件，建立所需要的依赖（例如库），初始化运行时环境并且开始执行。
    在UNIX中大家都知道，文件是可以有各种权限的，读、写、执行，针对不同角色，赋予权限，如果想给所有用户增加执行权限，chmod+x不用多讲，这中标识，只是系统认为，这个文件在系统中，可以去执行，至于是不是能够执行的文件，操作系统也要知道，操作系统通过一个叫“魔数”的文件头签名，这个签名是用来干什么的呢，它主要是操作系统内核将文件读入内存时， 寻找这个文件头签名，可以确定精确的可执行格式。
    那这个“魔数”以什么形式出现在文件头中呢，这个签名一般是预先定义好的，而且通常是任意选择的一个常量值。当文件被读入时，通过“魔数”可以帮助判断文件的二进制格式，如果是被支持的二进制格式，那么就会调用真确的加载器函数。下表列出了一些可执行文件的格式：

格式列表.png

    在这些不同的可执行格式中，OSX目前支持后三种：解释器脚本格式、通用二进制格式以及Mach-O格式。解释器脚本格式实际只是一种特殊形式的二进制文件格式。因为这些文件只不过是指向“真正”二进制的脚本，而这些被指向的文件才是真正得到执行的文件。因此我们只需要讨论两种格式------------通用二进制格式和Mach-O格式。

通用二进制格式

    OS X中推出了其非常创新的“通用二进制(Universal Binary)”这一概念。这个格式的基本思想是提供一种能够在任意架构上执行的完全可移植的二进制格式，OS X最早是构建于PowerPC(PPC)架构之上的，后来移植到了Intel架构(自从Tiger 10.4.7开始)。通用二进制文件可以在PPC和x86两种处理器上执行。
    不过实际上，通用二进制格式只不过是其支持的各种架构的二进制文件的打包文件。也就是说，这种格式的文件包含一个非常简单的文件头，文件头后面一次拷贝了每一种支持架构的二进制文件。Snow Leopard（雪豹）中的大部分二进制文件只包含Intel架构的镜像，但是为了支持32位编译和64位编译的代码，仍然使用了通用二进制格式。不过有少量文件仍然包含支持PowerPC架构的镜像。在Snow Leopard之前（含），OS X还包含一个叫做“Rosetta”的可选组件，这个组件允许在Intel架构的处理器上模拟PowerPC。然而从Lion开始，官方已经正式移除了PowerPC的支持，因此二进制文件中再也不包含任何支持PPC的镜像了。
    输出清单4-2中的例子显示了/bin/ls包含两种架构的二进制：32位Intel版本（i386）和64位Intel版本（x86_64）。在Snow Leopard中有少量的二进制文件还包含了PowerPC版本（ppc），例如/usr/bin/perl.如下图

通过file命令查看通用二进制格式的文件.png

通过file命令查看通用二进制格式的文件.png

    通过这种方式包含同一份二进制文件的多个版本的拷贝显然会极大地增加二进制文件的大小。事实上，通用二进制文件往往非常庞大，因而“通用二进制”这个名字在市场关注度不高，反而是“胖二进制”这个别名更朗朗上口。通用二进制文件的处理工具因此有一个非常恰当的名字叫做lipo（中文含义为“脂肪”）。这个工具可以提取、删除或替换通用二进制文件中指定架构的二进制代码，因此可以用于对通用二进制文件进行“瘦身”。这个工具还可以显示胖二进制文件头的详细信息：通过lipo(1)命令可以查看各种二进制文件的胖文件头。在下面的例子中，我们查看系统中的Perl解释器：

查看头信息.png

查看头信息.png

    通过arch(1)命令，可以强制加载二进制文件中的某个特定架构的二进制：
    

image.png

    在Snow Leopard之前（含）的Mac OS X安装盘中的Optional Installs目录中确实包含了Rosetta的安装器，但是最终在Lion中还是被移除了。如果在Lion中还是被移除了。如果在Lion中尝试这个实验，将无法看到任何PPC相关的二进制--不过在iPhone SDK中的gdb文件中可以看到多个平台gdb的混合体。

image.png

    通用二进制文件的格式定义在头文件中，如图所示：

image.png

    尽管通用二进制文件会占用大量的磁盘空间，但是OS X可以通过这个结构自动地挑选最合适底层硬件平台的二进制代码执行。调用一个二进制文件时，Mach加载器会首先解析胖二进制文件头，确定其中可用的架构----------等同于lipo命令展示的那些架构。然后只加载最合适的架构的代码。因此不相关的架构的代码不会占用任何内存。事实上，通用二进制文件的镜像都做了优化，对齐页边界，因此内核只需要加载二进制文件的第一个页面就可以读取文件头，而这个文件头实际上可以当做一个目录，内核根据这个目录继续加载合适的镜像。
    系统根据cputype和cpusubtype挑选最匹配当前处理器的镜像（通过arch命令可以修改这个行为）。具体说来，将二进制文件匹配至具体的架构的工作是由中的函数完成的。架构信息保存在NXArchInfo结构体中，这个结构体中保存了CPU类型、cpusubtype以及自己顺序等信息（还包含文本的描述信息）。NXGetLocalArchInfo（）函数负责获得主机的架构信息，NXFindBestFatArch（）返回最匹配的架构（如果没有匹配则返回NULL）。这里有一段代码，用到了这些API中部分函数的用法。

#include 
#include 

const char *ByteOrder(enum NXByteOrder BO)
{
    switch (BO) {
        case NX_LittleEndian:
            return ("Little-Endian");
        case NX_BigEndian:
            return ("Big-Endian");
        case NX_UnknownByteOrder:
            return ("Unknow");
        default:
            break;
    }
}

int main(int argc, const char * argv[]) {
    
    
    const NXArchInfo *local = NXGetLocalArchInfo();
    const NXArchInfo *known = NXGetAllArchInfos();
    
    while (known && known->description) {
        printf("Known: %s\t%x/%x\t%s\n",known->description,
               known->cputype, known->cpusubtype, ByteOrder(known->byteorder));
    }
    
    if (local) {
        printf("Local - %s\t%x/%x\t%s\n",local->description,
               local->cputype, local->cpusubtype, ByteOrder(local->byteorder));
    }
    
    return 0;
}