Shulou(Shulou.com)06/01 Report--

Editor to share with you the example analysis of System.map files. I hope you will get something after reading this article. Let's discuss it together.

There seems to be a lack of information about System.map files. In fact, it is not mysterious at all, and it is not as important as it seems in the whole thing. However, due to the lack of necessary documentation, it seems more mysterious. It's like an earlobe. We all have it, but we don't know what it's for. This page is used to illustrate this problem.

Note that I will not be 100% correct. For example, a system probably doesn't have / proc filesystem support, but most systems definitely do. Here I assume that you are "following the crowd" and have a typically configured system.

Some of the exposition of kernel errors (oops) comes from Alessandro Rubini's book Linux device drivers, from which I learned most about kernel programming.

What is a Symbols?

In programming, a symbol is the creation block of a program: it is a variable name or a function name. Like your own programs, it should not be surprising that the kernel has a variety of symbols. The difference, of course, is that the kernel is a very complex block of code and contains many, many global symbols.

What is a kernel symbol table (Kernel Symbol Table)?

The kernel does not use symbolic names. It uses a variable or function by its address (pointer) rather than size_t BytesRead, which the kernel prefers to use (for example) c0343f20 to refer to this variable.

On the other hand, people don't like names like c0343f20. We like to use expressions like size_t BytesRead. Usually, this doesn't cause any problems. The kernel is mainly written in C, so the compiler / linker allows us to use symbolic names when we program, and causes the kernel to use address representation at run time. So everyone is satisfied.

However, there is a situation where we need to know the address of a symbol (or the symbol corresponding to an address). This is done through a symbol table, similar to how gdb can give a function name from an address (or the address of a function name). A symbol table is a list of all symbols and their corresponding addresses. Here is an example of a symbolic table:

C03441a0 B dmi_brokenc03441a4 B is_sony_vaio_laptopc03441c0 b dmi_identc0344200 b pci_bios_presentc0344204 b pirq_tablec0344208 b pirq_routerc034420c b pirq_router_devc0344220 b ascii_bufferc0344224 b ascii_buf_bytes

You can see that the variable named dmi_broken is located at the kernel address c03441a0.

What is a System.map file?

Two files are used as symbol tables:

/ proc/ksymsSystem.map

Here, you can now know what the System.map file is for.

Every time you compile a new kernel, the addresses of the various symbolic names will change.

/ proc/ksyms is a "proc file" and is created at kernel startup. It's not really a real file; it's just a simple representation of kernel data that looks like a disk file. If you don't believe me, try to find out the file size of / proc/ksyms. Therefore, for the currently running kernel, it is always correct..

However, System.map is a real file on the file system. When you compile a new kernel, the symbolic information in your original System.map is incorrect. With each compilation of the kernel, a new System.map file is generated and needs to be replaced with the original file.

What is an Oops?

What are the most common errors in your own programs? Is a segment error (segfault), signal 11.

What is the most common bug in the Linux kernel? It's also a paragraph error. Besides, as you can imagine, the problem of paragraph errors is very complex and serious. When the kernel references an invalid pointer, it is not called a segment error-it is called "oops". An oops indicates that there is a bug in the kernel, and the bug should always be reported and corrected.

Note that an oops is not the same thing as a segment error. Your program does not recover from segment errors, and when an oops appears, it does not mean that the kernel must be in an unstable state. The Linux kernel is very robust; an oops may only kill the current process and leave the rest of the kernel in a good, stable state.

An oops is not a kernel panic. After the kernel calls the panic () function, the kernel cannot continue to run; the system is in a standstill state and must be rebooted. If a critical part of the system is destroyed, an oops may also cause the kernel to enter a panic. For example, the presence of oops in a device driver rarely causes the system to go into an endless loop.

When an oops appears, the system displays information about the debugging problem, such as the contents of all CPU registers and the location of the page descriptor table, especially the contents of the EIP (instruction pointer) as follows:

EIP: 0010: [] Call Trace: [] what does an Oops have to do with a System.map file?

I think you would also think that EIP and Call Trace don't give much information, but importantly, it's not enough for kernel developers. Because a symbol does not have a fixed address, c010b860 can point anywhere.

To help us use oops's ambiguous output, Linux uses a daemon called klogd (kernel log daemon). Klogd intercepts kernel oops and uses syslogd to record it, and converts information like c010b860 into information that we can identify and use. In other words, klogd is a kernel message logger (logger) that performs name-to-address resolution. Once klogd starts converting kernel messages, it uses the logger at hand to record messages for the entire system, usually using the syslogd logger.

For name-address resolution, klogd uses the System.map file. I think you now know the relationship between oops and System.map.

In-depth explanation: in fact, klogd will perform two types of address resolution activities.

Static conversion, will use the System.map file. Dynamic conversion, which is used for loadable modules and does not use System.map, is not relevant to this discussion, but I will explain it briefly.

Klogd dynamic conversion assumes that you load a kernel module that generates oops. An oops message is generated, and klogd intercepts it and finds that the oops occurs at d00cf810. Because this address belongs to the dynamically loaded module, there is no corresponding entry in the System.map file. Klogd will look for it and will find nothing, so it is concluded that a loadable module generated the oops. At this point, klogd queries the kernel for the symbols output from the loadable module. Even if the composer of the module does not output its symbols, klogd will at least know which module generated the oops, which is better than knowing nothing about an oops. There are other software that will use System.map, which I will explain later.

Where should the System.map be located?

System.map should be located where the software that uses it can find it, that is, where klogd will look for it. When the system starts up, if the location of the System.map is not given to the klogd in the form of a parameter, the klogd will search for System.map in three places. The order is as follows:

/ boot/System.map/System.map/usr/src/linux/System.map

System.map also contains version information, and klogd can intelligently search for the correct map file. For example, suppose you are running kernel 2.4.18 and the corresponding map file is located in / boot/System.map. Now you compile a new kernel 2.5.1 in the directory / usr/src/linux. During compilation, the file / usr/src/linux/System.map is created. When you boot the new kernel, klogd will first query / boot/System.map to confirm that it is not the correct map file for the boot kernel, then query / usr/src/linux/System.map, make sure that the file is the correct map file for the boot kernel and start reading the symbol information in it.

A few points to pay attention to:

In a version of the 2.5.x kernel, the Linux kernel will start to untar into linux-version instead of just linux (show of hands-how many people have been waiting to do so?). I don't know if klogd has been modified to search in / usr/src/linux-version/System.map. TODO: view the klogd source code. There is no complete description of this in the online manual, see: strace-f / sbin/klogd | grep 'System.map' 31208 open ("/ boot/System.map-2.4.18", O_RDONLY | O_LARGEFILE) = 2 obviously, not only does klogd look for the correct version of the map file in three search directories, but klogd also knows to look for the name "System.map" plus "- kernel version", like System.map-2.4.18. This is an undisclosed feature of klogd.

Some drivers will use System.map to parse symbols (because they are connected to kernel headers rather than glibc libraries, etc.) and will not work correctly without System.map files. This is different from a module that is not loaded because the kernel version does not match. Module loading is related to the kernel version and has nothing to do with the compiled kernel whose symbol table changes even in the same version of the kernel.

Who else uses System.map?

Don't think that System.map files are only useful for kernel oops. Although the kernel itself does not actually use System.map, other programs, such as klogd,lsof, satan# strace lsof 2 > & 11 > / 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

And many other software, like dosemu, need to have a correct System.map file.

What will happen if I don't have a good System.map?

Suppose you have multiple cores on the same machine. Each kernel needs a separate System.map file! If the kernel you are booting does not have a corresponding System.map file, you will see a message periodically: System.map does not match actual kernel (System.map does not match the actual kernel) is not a fatal error, but it appears annoyingly every time you execute ps ax. Some software, such as dosemu, may not work properly. Finally, when a kernel oops appears, the output of klogd or ksymoops may be unreliable.

How can I remedy the above situation?

The way to do this is to put all your System.map files in the directory / boot and rename them with the kernel version number. Suppose you have the following cores:

/ boot/vmlinuz-2.2.14/boot/vmlinuz-2.2.13

Then, just rename the map file for each kernel version and put it under / boot, such as:

/ boot/System.map-2.2.14 / boot/System.map-2.2.13

What if you have two copies of the same kernel? For example:

/ boot/vmlinuz-2.2.14/boot/vmlinuz-2.2.14.nosound

The best solution would be for all software to find the following files:

/ boot/System.map-2.2.14 / boot/System.map-2.2.14.nosound

But to be honest, I don't know if this is the best-case scenario. I've seen searching for "System.map-kernelversion", but what about searching for "System.map-kernelversion.othertext"? I'm not certain. All I can do at this point is to take advantage of the fact that / usr/src/linux is the search path for standard map files, so your map file will be placed in:

/ boot/System.map-2.2.14/usr/src/linux/System.map (for nosound version)

You can also use symbolic links:

System.map-2.2.14System.map-2.2.14.soundSystem.map-> System.map-2.2.14.sound has finished reading this article, I believe you have some understanding of "sample Analysis of System.map documents". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.