The different uses of adb kadb

The different uses of adb & kadb

Whether you want to use adb to look at a user program that dumped core , to look at a live, running system, or to examine the postmortem files of a system that crashed, you will usually use adb with two files: the object file and the core file.

The object file

The executable object file can be either a program or a kernel. The file contains the symbol table and the executable code. The symbol table is not required; however, without it, you can't use the symbolic features of adb .

The object file serves two purposes. First, you can examine the initialized data values in the executable to find the contents of variables when the program or kernel was first loaded. Second, the symbol table is kept within the executable object file. The symbol table enables adb or any other debugger to match symbolic names with real addresses. While adb doesn't really care, humans seem to respond better to functions or variables that have names rather than just hexadecimal addresses.

The core file

The second file is the core file. When used for postmortem analysis of a program or a kernel, the core file is an image that reflects a snapshot of the memory in use by the failed program or kernel at the time of failure. When a live system is viewed , the core file reflects the memory currently in use by the kernel.

If you, for whatever reason, don't have access to both the object file and the core file, you can specify a dash, " - ", in its place on the command line when you invoke adb .

Using adb on crash dumps

User programs, utilities, and kernel core files can be debugged with adb . Programs that crash may leave a file, called core , in the current working directory. This core file can be examined along with the executable file to identify the cause and location of the error. Of course, if you don't have the source to the program, you will find debugging to be a lot of work! Remember, you will be working with assembly code.

In Chapter 3, "The savecore Program", we talked about how system crashes are captured. savecore files normally include all of the kernel data space, if not the entire contents of physical memory. The adb -k flag is used when analyzing system crash dump savecore files and live systems, because adb needs to do a lot of work with address translation for the kernel data space.

We'll briefly explore both types of crashes, program core dumps and system crash dumps, later on in this chapter.

Using adb on live systems

As we've already mentioned, adb is not limited to debugging postmortem files. As a matter of fact, it is common practice to use adb to modify or tune a running system in hopes of gaining better performance. adb can also be used to modify the kernel so that the next reboot will change the system's behavior.

By default, adb is used to only look at or read the object and core files. However, by use of either the -w flag when invoking adb or the $W command within adb , adb can be used to write to the files.

Note

You must be extremely careful when working on live system kernels , since a write to the wrong location can have disastrous effects, as you've already discovered in Chapter 5, where we crashed your own system!

The kernel resident absolute debugger, kadb

In some cases, it may be easier and more productive to take over a crashed machine and examine the system right then and there as opposed to looking at a system crash dump later. This obviously works best on a system that can be left down long enough to let you perform some diagnosis at your leisure. Servers with 500 users all breathing down your neck don't allow for a calm, quiet, analysis session.

If you are in a position to debug a live system, kadb is the debugger you will use. kadb is made available by actually booting the debugger initially instead of the operating system. kadb then loads in and starts the rest of the kernel. When something causes a panic, kadb takes over and leaves the system more or less in the state in which it died. At this point, kadb is ready to work with you.

The interactive capability of kadb can have major advantages when, for example, you are looking at panics caused by a device driver you are trying to install and debug. The driver is loaded, the device is available, which is not the case when looking at a set of postmortem files, and all of the kernel data is right there. Using kadb, you can set breakpoints and treat the kernel just like a great, big, user program, stepping through its execution, examining and modifying values on-the-fly .

Working with adb on system crash dump postmortem files doesn't provide this level of interaction with your patient, the system, since you are really dealing with a computer corpse at that point. Also, the process of panic'ing and dumping core alters the state of the system, occasionally just enough so that you lose critical crash information.