Compilation of System.map file: Zhao Wei www.plinux.org (GoHigh@sh163.net)
Information about system.map files is very lacking. In fact, it is not mysterious, and it is not like it is so important at the whole thing. However, due to the lack of necessary documentation, it looks a relatively mysterious. It is like an earlobe, and each of us has, but it doesn't know what to do. This page is used to illustrate this problem.
Note that I will not be a hundred percent. For example, a system is likely to have no / proc file system support, but most systems are certain. Here I assume that you are "with great flow" and have a typical system.
Some of the elaboration of the kernel error (OOPS) comes from the "Linux Device Driver" book from Alessandro Rubini, I learned most of the kernel programming knowledge.
What is symbols?
In the program, a symbol (Symbol) is a program creation block: it is a variable name or a function name. Just like the procedure you have prepared, the kernel has various symbols and should not be surprised. Of course, the difference is that the kernel is a very complex code block and contains many, many global symbols.
What is the kernel symbol table?
The kernel does not use the symbol name. It is an address (pointer) of a variable or function that uses a variable or function, rather than using SIZE_T BYTESREAD, the kernel prefer to use (for example) C0343F20 to reference this variable.
On the other hand, people don't like the names like C0343F20. We use the representation of the like size_t bytesRead. Usually, this will not bring any problems. The kernel is mainly written in C language, so the compiler / connection program allows us to use the symbol name when we program, and the kernel uses the address representation. So everyone is satisfied.
However, there is a case where we need to know the address of a symbol (or a symbol corresponding to the address). This is made through the symbolic table, and the GDB can give a function name from an address (or adding an address of a function name). The symbol table is a list of all symbols and their corresponding addresses. Here is a symbol table example:
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
You can see that the variable named Dmi_Broken is located at the kernel address C03441A0.
What is the system.map file?
Two files are used as symbolic tables:
/ proc / ksyms system.map
Here, you can now know what the system.map file is dry.
Whenever you compile a new kernel, the address of the various symbolists will change.
/ proc / ksyms is a "proc file" and is created when the kernel is started. In fact it is not a real file; it is just a simple representation of kernel data, which presents like a disk file. If you don't believe me, try to find the size of the / proc / ksyms. Therefore, it is always correct for the currently running kernel..
However, System.map is a real file on the file system. When you compile a new kernel, the symbol information in your original system.map is not correct. As each kernel is compiled, a new system.map file is generated, and the original file is required to replace the file. What is an OOPS?
What is the most common error situation in the program prepared in your own procedure? Segfault, signal 11.
What is the most common bug in the Linux kernel? It is also wrong. In addition, as you think, the problem with the paragraph is very complicated, and it is also very serious. When the kernel references an invalid pointer, it is not called the paragraph error - and is called "OOPS". An OOPS indicates that there is a bug in the kernel, and it should always be reported and revised the bug.
Please note that an OOPS is wrong with a paragraph is not a matter. Your program cannot recover from a paragraph error. When an OOPS has an OOPS, it does not mean that the kernel is definitely in an unstable state. The Linux kernel is very robust; an OOPS may only kill the current process and make the remainder of the kernel in a good, stable state.
An OOPS is not a kernel cycle (PANIC). After the kernel calls the PANIC () function, the kernel cannot continue to run; at this time the system is in a pause state and must be restarted. If the key part of the system is destroyed, then an OOPS may also cause the kernel to enter the dead cycle (PANIC). For example, OOPs that appear in the device driver will hardly lead to a systematic cycle.
When an OOPS appears, the system displays related information for debugging issues, such as the contents of all CPU registers, and the location of the page descriptor table, especially the content of the EIP (instruction pointer) is printed below:
EIP: 0010: [<00000000>]
Call TRACE: [
]
What is the relationship between an OOPS with the System.map file?
I think you will also think that the information given by EIP and Call Trace is not much, but it is important that these information is not enough for kernel developers. Since a symbol does not have a fixed address, C010B860 can point to anywhere.
To help us use the OOPS vague output, Linux uses a background program called Klogd (Nuclear Log Back-stage), Klogd will intercept the kernel OOPS and use syslogd to record it, and convert some icon C010B860 to us Information can be identified and used. In other words, Klogd is a kernel message recorder (Logger) that can be parsed between name-address. Once Klogd starts to convert kernel messages, it uses a hand recorder to record the message of the entire system, usually using the Syslogd recorder.
To make a name-address resolution, Klogd is used to use the System.map file. I think you know that an OOPS is related to System.map.
In-depth explanation: In fact, KlogD will perform two types of address parsing activities.
Static conversion will use the System.map file. Dynamic conversion, this method is used to load the module, which does not use system.map, so it is not a relationship with this discussion, but I will still briefly explain it.
KlogD dynamic conversion
Suppose you load a kernel module that produces OOPS. So I will generate an OOPS message, Klogd will intercept it and find that the OOPS occurs at D00CF810. Since this address is a dynamic loading module, there is no corresponding entry in the system.map file. Klogd will find and do nothing, so that it is a loadable module to generate OOPS. At this time, Klogd will query the symbol output of the loaded module to the kernel. Even if the description of the module does not output its symbol, Klogd also at least will know which module produces OOPS, which is always better than an OOPS. Also other software will use system.map, I will explain it later.
Where should System.map be in place?
System.map should be located where the software can be found, that is, Klogd will look for it. When the system is started, if there is no location of Klogd in the form of a parameter, Klogd will search SYSTEM.MAP in three places. as followed:
/BOOT/system.map /system.map /usr/src/linux/system.map
System.map also contains version information, and KlogD can search for the correct MAP file intelligently. For example, suppose you are running the kernel 2.4.18 and the corresponding MAP file is located in /boot/system.map. Now you compile a new core 2.5.1 in the directory / usr / src / linux. During the compilation, file /usr/src/linux/system.map will be created. When you start the new kernel, Klogd will first query /boot/system.map, confirm that it is not the correct MAP file that launches the kernel, query /usr/src/linux/system.map, determine that the file is starting the kernel The MAP file and start reading the symbol information.
Several attention:
At a version of the 2.5.x series core, the Linux kernel will start Untar into Linux-Version, not just Linux (please raise your table - how many people have been waiting for this?). I don't know if Klogd has been modified to search in /usr/src/linux-version/system.map. TODO: View Klogd Source Codes. There is no complete description on the online manual, please see: # strult -f / sbin / klogd | grep 'system.map'
31208 Open ("/ boot / system.map-2.4.18", o_rdonly | o_largefile) = 2
Obviously, not only Klogd is looking for the correct version of the MAP file in three search directories, Klogd also knows that the name "system.map" is "- kernel version", like system.map-2.4.18. This is Klogd Open characteristics.
Some drivers will use system.map to resolve symbols (because they are connected to the internal nuclear head, without the glibc library, if there is no system.map file, they will not work correctly. This is two yards with a module because the kernel version does not match. The module load is related to the kernel version, and the compilation of the compiled kernel as the same version of the kernel is also changed.
Who else uses system.map?
Don't think the System.map file is only useful to kernel OOPS. Although the kernel itself does not actually use system.map, other programs, like Klogd, LSOF,
Satan # straape lsof 2> & 1 1> / dev / null | grep system
Readlink ("/ Proc / 22711 / FD / 4", "/Boot/system.map-2.4.18", 4095) = 23PS,
Satan # strult PS 2> & 1 1> / dev / null | GREP SYSTEM
Open ("/ boot / system.map-2.4.18", o_rdonly | o_nonblock | o_nock = 6
And many other software, like Dosemu, need to have a correct
SYSTEM.MAP file.
What happens if I don't have a good system.map?
Suppose you have multiple kernels on the same machine. Each kernel needs a separate system.map file! If the kernel starts does not have a corresponding system.map file, then you will periodically see such a message:
System.Map Does Not Match Actual Kernel (System.map does not match the actual kernel)
Not a fatal mistake, but whenever you execute
PS AX will annoying. Some software, such as DOSemu, may not work properly. Finally, when a kernel OOPS occurs, the output of Klogd or Ksymoops may be unreliable.
How do I remedy the above situation?
The method is to put all your system.map files under directory / boot and rename them with the kernel version number. Suppose you have multiple kernels below:
/BOOT /VMLINUZ-2.2.14 /Boot/Vmlinuz-2.2.13
So, just to change the MAP file corresponding to each core 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? E.g:
/ Boot/Vmlinuz-2.2.14 /boot/vmlinuz-2.2.14.nosound
The best solution will be that all software can find the following files:
/BOOT/system.map-2.2.14
/ Boot/system.map-2.2.14.nosound
But right, I don't know if this is the best situation. I have seen the search for "system.map-kernelversion", but for searching for "system.map-kernelversion.OTHERTEXT"? I am not very clear. At this point, what I can do is to use this fact: / usr / src / linux is the search path of the standard MAP file, so your Map file will be put:
/BOOT/SYSTEM.MAP-2.2.14 /usr/src/linux/system.map (for the NOSID version)
You can also use symbolic connections:
SYSTEM.MAP-2.2.14
System.map-2.2.14.sound
System.map -> System.map-2.2.14.Sound
