为了帮助我们使用oops含糊的输出，Linux使用了一个称为klogd(内核日志后台程序)的 后台程序，klogd会截取内核oops并且使用syslogd将其记录下来，并将某些象c010b860 的信息转换成我们可以识别和使用的信息。换句话说，klogd是一个内核消息记录器(logger)， 它可以进行名字-地址之间的解析。一旦klogd开始转换内核消息，它就使用手头的记录器， 将整个系统的消息记录下来，通常是使用syslogd记录器。
为了进行名字-地址解析，klogd就要用到System.map文件。我想你现在 知道一个oops与System.map的关系了。
深入说明： 其实klogd会执行两类地址解析活动。
静态转换，将使用System.map文件。
动态转换，该方式用于可加载模块，不使用System.map，因此与本讨论没有关系，但我仍然对其加以简单说明。
Klogd动态转换
假设你加载了一个产生oops的内核模块。于是就会产生一个oops消息，klogd就会截获它，并发现该oops发生在d00cf810处。由于该地址属于动态加载模块，因此在System.map文件中没有对应条目。klogd将会在其中寻找并会毫无所获，于是断定是一个可加载模块产生了oops。此时klogd就会向内核查询该可加载模块输出的符号。即使该模块的编制者没有输出其符号，klogd也起码会知道是哪个模块产生了oops，这总比对一个oops一无所知要好。
还有其它的软件会使用System.map，我将在后面作一说明。
System.map应该位于什么地方?System.map应该位于使用它的软件能够寻找到的地方，也就是说，klogd会在什么地方寻找它。在系统启动时，如果没有以一个参数的形式为klogd给出System.map的位置，则klogd将会在三个地方搜寻System.map。依次为：
/boot/System.map
/System.map
/usr/src/linux/System.map
System.map 同样也含有版本信息，并且klogd能够智能化地搜索正确的map文件。例如，假设你正在运行内核2.4.18并且相应的map文件位于/boot/System.map。现在你在目录/usr/src/linux中编译一个新内核2.5.1。在编译期间，文件 /usr/src/linux/System.map就会被创建。当你启动该新内核时，klogd将首先查询 /boot/System.map，确认它不是启动内核正确的map文件，就会查询 /usr/src/linux/System.map, 确定该文件是启动内核正确的map文件并开始读取其中的符号信息。
几个注意点:
在2.5.x系列内核的某个版本，Linux内核会开始untar成linux-version，而非只是linux (请举手表决 -- 有多少人一直等待着这样做?)。我不知道klogd是否已经修改为在/usr/src/linux-version/System.map中搜索。TODO：查看klogd源代码。
在线手册上对此也没有完整描述，请看：
strace -f /sbin/klogd | grep 'System.map'31208 open("/boot/System.map-2.4.18", O_RDONLY|O_LARGEFILE) = 2
显然，不仅klogd在三个搜索目录中寻找正确版本的map文件，klogd也同样知道寻找名字为 "System.map" 后加"-内核版本"，象 System.map-2.4.18. 这是klogd未公开的特性。
有一些驱动程序将使用System.map来解析符号(因为它们与内核头连接而非glibc库等)，如果没有System.map文件，它们将不能正确地工作。这与一个模块由于内核版本不匹配而没有得到加载是两码事。模块加载是与内核版本有关，而与即使是同一版本内核其符号表也会变化的编译后内核无关。
还有谁使用了System.map?不要认为System.map文件仅对内核oops有用。尽管内核本身实际上不使用System.map，其它程序，象klogd，lsof，
satan# strace lsof 2>&1 1> /dev/null | grep System
readlink("/proc/22711/fd/4", "/boot/System.map-2.4.18", 4095) = 23
ps,
satan# strace ps 2>&1 1> /dev/null | grep System
open("/boot/System.map-2.4.18", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 6
以及其它许多软件，象dosemu，需要有一个正确的System.map文件。
如果我没有一个好的System.map，会发生什么问题?假设你在同一台机器上有多个内核。则每个内核都需要一个独立的 System.map文件！如果所启动的内核没有对应的System.map文件，那么你将定期地看到这样一条信息：
System.map does not match actual kernel (System.map与实际内核不匹配)
不是一个致命错误，但是每当你执行ps ax时都会恼人地出现。有些软件，比如dosemu，可能不会正常工作。最后，当出现一个内核oops时，klogd或ksymoops的输出可能会不可靠。
我如何对上述情况进行补救?方法是将你所有的System.map文件放在目录/boot下，并使用内核版本号重新对它们进行命名。假设你有以下多个内核：
/boot/vmlinuz-2.2.14
/boot/vmlinuz-2.2.13
那么，只需对应各内核版本对map文件进行改名，并放在/boot下，如：
/boot/System.map-2.2.14
/boot/System.map-2.2.13
如果你有同一个内核的两个拷贝怎么办？例如：
/boot/vmlinuz-2.2.14
/boot/vmlinuz-2.2.14.nosound
最佳解决方案将是所有软件能够查找下列文件：
/boot/System.map-2.2.14
/boot/System.map-2.2.14.nosound