System.map文件作用.docVIP

System.map文件的作用有关System.map文件的信息好象很缺乏。其实它一点也不神秘，并且在整个事情当中它并不象看上去那么得重要。但是由于缺乏必要的文档说明，使其显得比较神秘。它就象耳垂，我们每个人都有，但却不知道是干什么用的。本网页就是用来说明这个问题的。注意，我并不会是百分之一百正确的。例如，一个系统很可能没有/proc文件系统支持，但是大多数系统肯定有。这里我假定你是“随大流的”，并有一个典型配置的系统。某些有关内核出错(oops)的阐述来自于Alessandro Rubini的“Linux设备驱动程序” 一书，我是从其中学到大部分内核编程知识的。什么是符号(Symbols)?? ? 在编程中，一个符号(symbol)是一个程序的创建块：它是一个变量名或一个函数名。 正如你自己编制的程序一样，内核具有各种符号也是不应该感到惊奇的。当然，区别在 于内核是一非常复杂的代码块，并且含有许多、许多的全局符号。 内核符号表(Kernel Symbol Table)是什么东西?? ? 内核并不使用符号名。它是通过变量或函数的地址(指针)来使用变量或函数的，而 不是使用size_t BytesRead，内核更喜欢使用(例如)c0343f20来引用 这个变量。而另一方面，人们并不喜欢象c0343f20这样的名字。我们跟喜欢使用象 size_tBytesRead这样的表示。通常，这并不会带来什么问题。内核主要是用C语言写成的，所以在我们编程时编译器/连接程序允许我们使用符号名，并且使 内核在运行时使用地址表示。这样大家都满意了。? ? 然而，存在一种情况，此时我们需要知道一个符号的地址（或者一个地址对应的 符号）。这是通过符号表来做到的，与gdb能够从一个地址给出函数名（或者给出一个 函数名的地址）的情况很相似。符号表是所有符号及其对应地址的一个列表。这里是 一个符号表例子：? ?c03441a0 B dmi_broken? ?c03441a4 B is_sony_vaio_laptop? ?c03441c0 b dmi_ident? ?c0344200 b pci_bios_present? ?c0344204 b pirq_table? ?c0344208 b pirq_router? ?c034420c b pirq_router_dev? ?c0344220 b ascii_buffer? ?c0344224 b ascii_buf_bytes? ? ? ? ? ? 你可以看出名称为dmi_broken的变量位于内核地址c03441a0处。 什么是System.map文件?? ? 有两个文件是用作符号表的:? ?? ? 1. /proc/ksyms? ?? ? 2. System.map ? ? 这里，你现在可以知道System.map文件是干什么用的了。? ? 每当你编译一个新内核时，各种符号名的地址定会变化。/proc/ksyms 是一个 proc文件 并且是在内核启动时创建的。实际上它不是一个真实的文件；它只是内核数据的简单表示形式，呈现出象一个磁盘文件似的。如果你不相信我，那么就试试找出/proc/ksyms的文件大小来。因此， 对于当前运行的内核来说，它总是正确的..? ? 然而，System.map却是文件系统上的一个真实文件。当你编译一个新内核时，你原 来的System.map中的符号信息就不正确了。随着每次内核的编译，就会产生一个新的 System.map文件，并且需要用该文件取代原来的文件。 什么是一个Oops?? ? 在自己编制的程序中最常见的出错情况是什么?是段出错(segfault)，信号11。Linux内核中最常见的bug是什么?也是段出错。除此，正如你想象的那样，段出错的问题是非常复杂的，而且也是非常严重的。当内核引用了一个无效指针时，并不 称其为段出错 --而被称为oops。一个oops表明内核存在一个bug，应该总是提出 报告并修正该bug。? ? 请注意，一个oops与一个段出错并不是一回事。你的程序并不能从段出错中恢复 过来，当出现一个oops时，并不意味着内核肯定处于不稳定的状态。Linux内核是非常 健壮的；一个oops可能仅杀死了当前进程，并使余下的内核处于一个良好的、稳定的 状态。一个oops并非是内核死循环(panic)。在内核调用了panic()函数后，内核就不能继续运行了；此时系统就处于停顿状态并且必须重启。如果系统中关键部分遭到破坏那么一个oops也可能会导致内核进入死循环(panic)。例如，设备驱动程序中 出现的oops就几乎不会导致系统进行死循环。? ? 当出现一个oops时，系统就