内核链接脚本分析
vmlinux_32.lds.S文件分析
Overview
上图中显示了内核image的布局，其中深色部分位于内核的虚拟地址空间3G~4G，共有text、data、note三个segment，其中note segment又是包含在text segment中。每个segment包含多个section，后面我们会讲到这些section是如何生成的。在这之前，需要了解链接脚本用到的两个地址：虚拟地址（VMA）和加载地址（LMA）。这里虚拟地址和我们平常说的虚拟地址是一样的，即section[*]在目标文件加载后所在的虚拟地址。例如在一个可执行的ELF文件中，.text section的VMA是0x08048310，即.text section的基地址位于虚拟地址空间的0x08048310处。加载地址指section被加载到内存中的地址，对于应用程序来说它通常和VMA相同，但对于内核来说，LMA是指section被加载到的物理地址。例如内核.text的VMA是0xc1001000，则LMA是0x01001000。很明显，这就是我们所熟知的内核虚拟地址 = 物理地址 + 0xC0000000（3G）的identify mapping关系。
[*]前面提到目标文件的加载是若干segment被加载到内存中的过程，这和section的加载并不冲突。实际上，当我们不指定segment的LMA和VMA时，这个两个值取segment中第一个section的LMA、VMA。加载segment也就是将其包含的各个section加载到内存中的过程。
好了，下面我们来看看内核链接脚本是怎么干的。
链接脚本的开始
除去一些文件包含和宏定义，内核链接脚本以下面内容开始：
OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(phys_startup_32)
jiffies = jiffies_64;
PHDRS {
text PT_LOAD FLAGS(5); /* R_E */
data PT_LOAD FLAGS(7); /* RWE */
note PT_NOTE FLAGS(0); /* ___ */
}OUTPUT_FORMAT和OUTPUT都是链接脚本的关键字，它们指定了目标文件的格式和所运行平台的架构。ENTRY指定了整个目标文件的入口点（或入口函数），这里phys_startup_32是个地址，从名字我们就可以看出它是startup_32()函数的物理地址，在后面会看到该地址是如何计算得到的。
下面进入正题。PHDRS关键字描述了3个segment：text、data和note，它们分别具有PT_LOAD和PT_NOTE类型，并指定了每个segment的属性。PT_LOAD类型表示该segment是从文件加载入内存的，在这个上下文中文件应该指最后生成的内核image。FLAG关键字指定segment的属性，如注释所示，text segment为可读可执行、data segment为可读可写可执行，note段留到后面再说。至此，PHDRS定义了内核image的大体框架，它包含两个最主要的segment —— text和data，并确定了它们的属性，后面的代码就是向两个segment填充section了。
链接脚本知识：
PHDRS关键字的完整格式如下：
PHDRS
{
name type [ FILEHDR ] [ PHDRS ] [ AT ( address ) ]
[ FLAGS ( flags ) ] ;
}
其中name表示segment的名字，它位于单独的名字空间，不会和后面的section name冲突。type即segment的类型，如上的PT_LOAD，详细列表参见参考文献1。FILEHDR和PHDRS指定是否要包含ELF文件头和ELF程序头。AT指定segment的加载地址，FLAGS指定segment的属性。
构造Section
在构建了基本的segment后，就可以从输入.o文件中获取感兴趣的section以生成新的section并放入相应的segment。在这里，输入的section称为input section，生成的新section称为output section。除此之外，有一个重要的链接脚本符号“.”需要了解。”.”是个位置计数器，记录着当前位置在目标文件中的虚拟地址(VMA)。”.”是个自动增加的计数器，当一个output section生成后，”.”的值自动加上该output section的长度。我们也可以显式的给”.”赋值以改变当前位置的地址，这在内核链接脚本中被大量使用。一个例子可以很好的描述”.”的作用：
. = 0x100000;
_start_addr = .;
.text : { *(.text) }
_end_addr = . ;
这里我们首先给”.”赋了一个初值，将地址指定到0x100000处，并将该值赋给变量_start_addr，它是.text section的起始地址；接着我们生成了一个.text section，此时”.”自动加上该section的长度，可描述为 . = . + SIZEOF(.text)；最后将”.”赋值给_end_addr，记录下.text的结束地址。此时”.”的值变成了0x100000 + SIZEOF(.text)。有了”.”的帮助，我们可以灵活的控制目标文件中各个section所在的虚拟地址(VMA)。
Text Segment的构造
内核首先构造的是text segment，该segment又由若干个.text.*节构成，除此之外，它还包含了note segment的内容以及只读数据section。下面的代码完成了这些工作：
SECTIONS
{
. = LOAD_OFFSET + LOAD_PHYSICAL_ADDR;
phys_startup_32 = startup_32 - LOAD_OFFSET;
.text.head : AT(ADDR(.text.head) - LOAD_OFFSET) {
_text = .; /* Text and read-only data */
*(.text.head)
} :text = 0x9090
/* read-only */
.text : AT(ADDR(.text) - LOAD_OFFSET) {
. = ALIGN(PAGE_SIZE); /* not really needed, already page aligned */
*(.text.page_aligned)
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
KPROBES_TEXT
*(.fixup)
*(.gnu.warning)
_etext = .; /* End of text section */
} :text = 0x9090
NOTES :text :note
. = ALIGN(16); /* Exception table */
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
__start___ex_table = .;
*(__ex_table)
__stop___ex_table = .;
} :text = 0x9090
RODATA首先是SECTIONS关键字，官方的解释是“The SECTIONS command tells the linker how to map input sections into output sections, and how to place the output sections in memory.”，实际上可以把它看成一个描述符，所有的工作要在它的内部完成。就像你在C中定义一个结构体要以struct关键字开头一样。
构造的第一步是为”.”指定初值，之后所有section虚拟地址（VMA）都由该值计算得来（前面我们讲过，生成一个section后”.”的值会自动加上改section的长度）。这里初始值为LOAD_OFFSET + LOAD_PHYSICAL_ADDR，前者是我们熟知的内核虚拟地址空间起始地址0xC0000000，LOAD_PHYSICAL_ADDR是内核image加载的物理地址，由CONFIG_PHYSICAL_START计算得到。该物理地址是可以指定的，你可以在.config文件中找到它，也可以由make menuconfig得到，具体解释参考arch/x86/Kconfig文件的PHYSICAL_START条目。对于一般的x86架构，内核被加载到物理地址0x100000处，故”.”的初值为0xC0100000。接着
phys_startup_32 = startup_32 - LOAD_OFFSET;
计算了内核image的入口地址，这在前面已经提到。
开始构造section了。由于使用的语法是固定的，我们只需要了解一个例子，其余的就可举一反三。以第一个section为例：
.text.head : AT(ADDR(.text.head) - LOAD_OFFSET) {
_text = .; /* Text and read-only data */
*(.text.head)
} :text = 0x9090
.text.head指定了生成的section的名字，后面的冒号是固定语法。AT关键字前面介绍过，指定该section的加载地址（LMA），它的完整表达是
AT(expression)
括号中expression表达式指定LMA的值。在此例中该表达式由
ADDR(.text.head) - LOAD_OFFSET
计算得到。这里
ADDR(section)
计算section的虚拟地址，故.text.head的加载地址（LMA）是它的物理地址。在大括号内部，_text = .; 定义了一个全局变量，它的值为”.”的当前值，记录了整个text segment的起始地址.。在这里，由于_text变量前还没有任何section被创建，故_text有如下等价关系：
_text = ADDR(.text.head) = . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR;
*(.text.head)完成了具体的section创建工作，”*”代表所有输入的.o文件，括号中的.text.head指定了链接器感兴趣的section名。
*(text.head)
表示从所有输入文件中抽取名为.text.head的section并填充到目标文件的.text.head section中。
: text
指定了新生成section所在的segment，这里冒号后的text是segment名，可见内核的第一个section被放到了text segment。
= 0x9090
指定section的填充内容。从输入文件中抽取来的section由于代码对齐的缘故，其二进制的存放可能是不连续的，这里指定对section中的空隙用0x9090进行填充。0x90是汇编指令NOP的机器码，故相当于在不连续代码间填充空操作。至此，内核的第一个section就创建好了，它名为.text.head，由输入文件的.text.head section构成（并非所有文件都有.text.head section，链接器只从具有该section的文件中抽取内容），该section的虚拟地址（VMA）由”.”的值确定，加载地址(LMA)为其物理地址，section中不连续区域产生的间隙由0x9090填充，最后该section被放入了内核的text segment中。
通过objdump内核，我们可以看到关于该section的最终内容：
Sections:
Idx Name Size VMA LMA File off Algn
0 .text.head 00000375 c1000000 01000000 00001000 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
…………………………………………………………………………………………..
Disassembly of section .text.head:
c1000000 <_text>:
c1000000:>--f6 86 11 02 00 00 40 >--testb $0x40,0x211(%esi)
c1000007:>--75 14 >--jne c100001d <_text+0x1d>
c1000009:>--0f 01 15 1a e1 4d 01 >--lgdtl 0x14de11a
>--->--->---c100000c: R_386_32>-boot_gdt_descr
c1000010:>--b8 18 00 00 00 >--mov $0x18,%eax
c1000015:>--8e d8 >--mov %eax,%ds
…………………………………………………………………………………………………
c10013d5:>--5b >--pop %ebx
c10013d6:>--5e >--pop %esi
c10013d7:>--c9 >--leave--
c10013d8:>--c3 >--ret----
c10013d9:>--90 >--nop----
c10013da:>--90 >--nop----
c10013db:>--90 >--nop----
c10013dc:>--90 >--nop----
c10013dd:>--90 >--nop----
c10013de:>--90 >--nop----
c10013df:>--90 >--nop----其中最后一部分显示了填充0x9090产生的nop指令。
链接脚本知识：
创建一个section的完整格式是：
section [address] [(type)] : [AT(lma)]
{
output-section-command
output-section-command
...
} [>region] [:phdr :phdr ...] [=fillexp]
其中[address]参数在上例中没有提到，它指定了section的虚拟地址(VMA)，如果没有指定该参数及region参数，section的虚拟地址由当前”.”的值确定，正如上例我们看到的一样。Region用于将section分配给通过MEMORY关键字创建的内存描述块，内核链接脚本没使用它，本文也不关注。
通过这个例子，我们很容易就可以理解text segment中其它section的创建。例如接下来的第二个.text section，它的创建方法和.text.head类似，唯一不同的是这里多了一句：
. = ALIGN(PAGE_SIZE);
ALIGN(exp)关键字计算当前”.”值对齐到exp边界后的地址，即：
ALIGN(exp) = ( . + exp – 1) & ~(exp – 1);
此处在创建.text section前，将”.”对齐到了页边界，从第一个输入section的名字.text.page_aligned就可以看出，输入section的内容是有对齐要求的。内核使用了TEXT_TEXT等宏将不同类型的输入section进行了封装，展开后可以看到它们都是：
*(section_name)
的形式，和我们前面讲的一样，不再多做介绍。
从上面内容可以看出，输入文件中的section有各种各样的名字，如.text.head、.text.page_aligned、.text.hot等，并不是所有的section名都是标准的，绝大部分是内核使用GCC扩展生成的自定义名。举个例子，我们常见的__init宏，展开后如下：
#define __init __attribute__ ((__section__(“.init.text”)))
这里.init.text是个自定义的section，用__init修饰的函数编译后会被放到名为.init.text section中。
自定义的section极大的发挥了链接脚本的作用，让我们可以对代码中的函数、数据进行归类操作，同时还可以完成一些在程序中不易完成的功能。这很容易理解，如果我们都用GCC内置的section，何必要自定义链接脚本，用默认的不就好了。
链接脚本向我们展示了大量的自定义section，本人水平有限，无法一一弄清每个section的用途，但通过几个常见的典型例子，我们可以了解它们的用法。首先就以text segment中的exception table举例。
Exception Table
此exception table不是用于处理硬件异常的（那是IDT表的工作），但它确实和硬件异常有一点关系，具体来说是和Page Fault有关系。Exception Table的具体机制在内核文档”Exception”中有详细介绍，你可以在path_to_your_kernel_src/ Documentation/exception.txt中找到它。这里为了说明问题做一点简要介绍。
Linus为了避免内核在访问用户态地址时进行有效性检查带来的开销（我们总是需要这样的检查，虽然大部分情况下结果是成功的），利用了page fault的处理函数来完成这项任务，这样只有在真正访问了一个坏的用户态地址时检查才会发生。或许你会问：此时检查有什么用？一个例子就很容易说明问题，假设我们有一个函数叫is_user_addr_ok()，用于检查传入的用户态地址是否合法。那么，当地址非法时它能干什么？什么都不能干，仅仅是告诉内核：“这是个非法地址，你不要访问”。这样便带来了个问题，让它在90%的时间里告诉内核：“这是个合法地址，去吧！”是件很无聊的事情。既然该函数对非法地址无能为力，我们干脆就什么都不要干，直到内核真访问到一个非法地址时再告诉调用者：“噢，抱歉，您访问到一个非法地址。”不管用哪种方法，调用者遇到非法地址最终结果都是获得一个错误码，但后者明显省下了对合法地址进行检查的开销。让我们来看看如何用自定义section完成这个任务。
如果你顺着copy_from_user()向下找几层，会看到__get_user_asm宏，该宏展开后可读性太差，我们用下面的伪代码来描述它：
1: movb (%from),(%to) /*这里访问用户态地址，当地址非法时会产生一个page fault*/
2:
/*注意，后面的代码在最终的目标文件中不是跟在标号2后的*/
.section .fixup,"ax"
3: movl $ERROR_CODE,%eax
xorb %dl,%dl
jmp 2b
.section __ex_table,"a"
.align 4
.long 1b,3b
上面的伪代码描述了__get_user_asm宏的用途，它将用户态地址from中的内容拷贝到内核地址to。当from是个非法地址时，会产生page fault从而执行内核的do_page_fault()，在进行一系列检查处理后fixup_exception()被调用，该函数会调用search_exception_tables()查找exception table，将EIP设置成对应handler的地址并返回。至此该非法地址造成的错误就交由exception table中的handler处理了。
所有问题的归结到了exception table的建立和错误处理handler的设置。其实上面的伪代码已经告诉我们答案了。首先，标号”1”代表了可能产生page fault的EIP，当page fault产生时这个地址会被记录在struct pt_regs的ip字段中（不知道的看看do_page_fault()的参数）；其次，标号”3”是错误处理handler的地址，很明显，它只是返回了一个错误码(EAX是x86的返回值寄存器)。jmp 2b跳到了产生page fault的指令的下一条指令继续执行。这里
.section .fixup,"ax"
创建了名为.fixup的自定义section，并将整个handler放入其中。标号”1”后的代码是位于.text section的，故你看到它们在源代码里写在了一起，但在目标文件中去是分开的，它们在不同的section。
好了，我们已经有了会产生错误的代码地址，也有了错误处理handler的地址，
.section __ex_table,"a"
将它们放到了自定义的__ex_table section中(.long 1b,3b)，以如下格式存放：
出错地址，处理函数地址
内核用结构体struct exception_table_entry表示该格式，定义如下：
struct exception_table_entry {
unsigned long insn, fixup;
};
很明显，exception table的格式简单，表项的前4个字节是出错地址，后4个字节是处理函数的地址。
当在内核在不同位置调用copy_from_user()时，展开的__get_user_asm宏都会将可能出错的地址和处理函数的地址存入该源文件对应.o文件的__ex_table section中。链接脚本的如下代码：
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
__start___ex_table = .;
*(__ex_table)
__stop___ex_table = .;
} :text = 0x9090
将分散的__ex_table收集起来产生一张完整的exception表，并将表的起始地址和结束地址记录在__start___ex_table和__stop___ex_table两个全局变量中，从而search_exception_tables()函数可以顺利的索引该表。
这种通过自定义section和链接脚本构造表的技巧被大量使用，后面我们还会看到两个例子。在此先告一段落。
Note Segment
前面提到内核image分为三个segment，其中就有note segment，它是包含在text segment中的。NOTE segment被用于不同的vendor在ELF文件中添加一些标识，让运行这些二进制代码的系统确定能否为该ELF提供其所需要的系统调用接口。
NOTES :text :note
上面代码中，NOTE是一个宏，展开的格式和构建其它section的格式一样，这里”:text:note”表示把生成的section即加入text segment又加入note segment。从objdump的内容可以看到后者包含在前者之中，如下：
LOAD off 0x00001000 vaddr 0xc1000000 paddr 0x01000000 align 2**12
filesz 0x004de000 memsz 0x004de000 flags r-x
NOTE off 0x0037b844 vaddr 0xc137a844 paddr 0x0137a844 align 2**2
filesz 0x00000024 memsz 0x00000024 flags ---