This chapter introduces techniques you can use to monitor kernel code and trace errors under such trying circumstances.

printk

 printk(KERN_DEBUG "Here I am: %s:%i\n", _ _FILE_ _, _ _LINE_& _); printk(KERN_CRIT "I'm trashed; giving up on %p\n", ptr); 

Each string (in the macro expansion) represents an integer in angle brackets. Integers range from 0 to 7, with smaller values representing higher priorities.

 # 
echo 8 > /proc/sys/kernel/printk

It should now be apparent why the hello.c sample had the <1> markers; they are there to make sure that the messages appear on the console.

This is how the program works:

 int main(int argc, char **argv) {     char bytes[2] = {11,0}; /* 11 is the TIOCLINUX cmd number */      if (argc==2) bytes[1] = atoi(argv[1]); /* the chosen console */     else {         fprintf(stderr, "%s: need a single arg\n",argv[0]); exit(1);     }     if (ioctl(STDIN_FILENO, TIOCLINUX, bytes)<0) {    /* use stdin */         fprintf(stderr,"%s: ioctl(stdin, TIOCLINUX): %s\n",                 argv[0], strerror(errno));         exit(1);     }     exit(0); } 

How Messages Get Logged

If you happen to read the kernel messages by hand, after stopping klogd you'll find that the /proc file looks like a FIFO, in that the reader blocks, waiting for more data. Obviously, you can't read messages this way if klogd or another process is already reading the same data because you'll contend for it.

If the circular buffer fills up, printk wraps around and starts adding new data to the beginning of the buffer, overwriting the oldest data. The logging process thus loses the oldest data. This problem is negligible compared with the advantages of using such a circular buffer. For example, a circular buffer allows the system to run even without a logging process, while minimizing memory waste by overwriting old data should nobody read it. Another feature of the Linux approach to messaging is that printk can be invoked from anywhere, even from an interrupt handler, with no limit on how much data can be printed. The only disadvantage is the possibility of losing some data.

Turning the Messages On and Off

Here we show one way to code printk calls so you can turn them on and off individually or globally; the technique depends on defining a macro that resolves to a printk (or printf ) call when you want it to.

• Each print statement can be enabled or disabled by removing or adding a single letter to the macro's name.

• All the messages can be disabled at once by changing the value of the CFLAGS variable before compiling.

• The same print statement can be used in kernel code and user-level code, so that the driver and test programs can be managed in the same way with regard to extra messages.

  #undef PDEBUG             /* undef it, just in case */ #ifdef SCULL_DEBUG #  ifdef _ _KERNEL_ _      /* This one if debugging is on, and kernel space */ #    define PDEBUG(fmt, args...) printk( KERN_DEBUG "scull: " fmt,                                           ## args) #  else      /* This one for user space */ #    define PDEBUG(fmt, args...) fprintf(stderr, fmt, ## args) #  endif #else #  define PDEBUG(fmt, args...) /* not debugging: nothing */ #endif  #undef PDEBUGG #define PDEBUGG(fmt, args...) /* nothing: it's a placeholder */ 

To simplify the process further, add the following lines to your makefile:

  # Comment/uncomment the following line to disable/enable debugging DEBUG = y  # Add your debugging flag (or not) to CFLAGS ifeq ($(DEBUG),y)   DEBFLAGS = -O -g -DSCULL_DEBUG # "-O" is needed to expand inlines else   DEBFLAGS = -O2 endif  CFLAGS += $(DEBFLAGS) 

The macros shown in this section depend on a gcc extension to the ANSI C preprocessor that supports macros with a variable number of arguments. This gcc dependency shouldn't be a problem because the kernel proper depends heavily on gcc features anyway. In addition, the makefile depends on GNU's version of make ; once again, the kernel already depends on GNU make, so this dependency is not a problem.

But every driver has its own features and monitoring needs. The art of good programming is in choosing the best trade-off between flexibility and efficiency, and we can't tell what is the best for you. Remember that preprocessor conditionals (as well as constant expressions in the code) are executed at compile time, so you must recompile to turn messages on or off. A possible alternative is to use C conditionals, which are executed at runtime and therefore permit you to turn messaging on and off during program execution. This is a nice feature, but it requires additional processing every time the code is executed, which can affect performance even when the messages are disabled. Sometimes this performance hit is unacceptable.

More often than not, the best way to get relevant information is to query the system when you need the information, instead of continually producing data. In fact, every Unix system provides many tools for obtaining system information: ps, netstat, vmstat, and so on.

Two main techniques are available to driver developers for querying the system: creating a file in the /procfilesystem and using the ioctl driver method. You may use devfs as an alternative to /proc, but /proc is an easier tool to use for information retrieval.

Using the /proc Filesystem

/proc is heavily used in the Linux system. Many utilities on a modern Linux distribution, such as ps, top, and uptime, get their information from /proc. Some device drivers also export information via /proc, and yours can do so as well. The /proc filesystem is dynamic, so your module can add or remove entries at any time.

Fully featured /proc entries can be complicated beasts; among other things, they can be written to as well as read from. Most of the time, however, /proc entries are read-only files. This section will concern itself with the simple read-only case. Those who are interested in implementing something more complicated can look here for the basics; the kernel source may then be consulted for the full picture.

In both cases the kernel allocates a page of memory (i.e., PAGE_SIZE bytes) where the driver can write data to be returned to user space.

Both functions should return the number of bytes of data actually placed in the page buffer, just like the read implementation does for other files. Other output values are *eof and *start. eof is a simple flag, but the use of the start value is somewhat more complicated.

The main problem with the original implementation of user extensions to the /proc filesystem was use of a single memory page for data transfer. This limited the total size of a user file to 4 KB (or whatever was appropriate for the host platform). The start argument is there to implement large data files, but it can be ignored.

If your proc_read function does not set the *start pointer (it starts out NULL), the kernel assumes that the offset parameter has been ignored and that the data page contains the whole file you want to return to user space. If, on the other hand, you need to build a bigger file from pieces, you can set *start to be equal to page so that the caller knows your new data is placed at the beginning of the buffer. You should then, of course, skip the first offset bytes of data, which will have already been returned in a previous call.

Time for an example. Here is a simple read_procimplementation for the scull device:

  int scull_read_procmem(char *buf, char **start, off_t offset,                    int count, int *eof, void *data) {     int i, j, len = 0;     int limit = count - 80; /* Don't print more than this */      for (i = 0; i < scull_nr_devs && len <= limit; i++) {         Scull_Dev *d = &scull_devices[i];         if (down_interruptible(&d->sem))                 return -ERESTARTSYS;         len += sprintf(buf+len,"\nDevice %i: qset %i, q %i, sz %li\n",                        i, d->qset, d->quantum, d->size);         for (; d && len <= limit; d = d->next) { /* scan the list */             len += sprintf(buf+len, "  item at %p, qset at %p\n", d,                                      d->data);             if (d->data && !d->next) /* dump only the last item                                                      - save space */                 for (j = 0; j < d->qset; j++) {                     if (d->data[j])                         len += sprintf(buf+len,"    % 4i: %8p\n",                                                     j,d->data[j]);                 }         }         up(&scull_devices[i].sem);     }     *eof = 1;     return len; } 

This is a fairly typical read_procimplementation. It assumes that there will never be a need to generate more than one page of data, and so ignores the start and offset values. It is, however, careful not to overrun its buffer, just in case.

A /proc function using the get_info interface would look very similar to the one just shown, with the exception that the last two arguments would be missing. The end-of-file condition, in this case, is signaled by returning less data than the caller expects (i.e., less than count).

  create_proc_read_entry("scullmem",                         0    /* default mode */,                        NULL /* parent dir */,                         scull_read_procmem,                         NULL /* client data */); 

The directory entry pointer can be used to create entire directory hierarchies under /proc. Note, however, that an entry may be more easily placed in a subdirectory of /proc simply by giving the directory name as part of the name of the entry -- as long as the directory itself already exists. For example, an emerging convention says that /proc entries associated with device drivers should go in the subdirectory driver/; scull could place its entry there simply by giving its name as driver/scullmem.

   remove_proc_entry("scullmem", NULL /* parent dir */); 

    static int scull_get_info(char *buf, char **start, off_t offset,                 int len, int unused) {     int eof = 0;     return scull_read_procmem (buf, start, offset, len, &eof, NULL); }  struct proc_dir_entry scull_proc_entry = {         namelen:    8,         name:       "scullmem",         mode:       S_IFREG | S_IRUGO,         nlink:      1,         get_info:   scull_get_info, };  static void scull_create_proc() {     proc_register_dynamic(&proc_root, &scull_proc_entry); }  static void scull_remove_proc() {     proc_unregister(&proc_root, scull_proc_entry.low_ino); }  

The code declares a function using the get_infointerface and fills in a proc_dir_entry structure that is registered with the filesystem.

The ioctl Method

As an alternative to using the /proc filesystem, you can implement a few ioctl commands tailored for debugging. These commands can copy relevant data structures from the driver to user space, where you can examine them.

Using ioctl this way to get information is somewhat more difficult than using /proc, because you need another program to issue the ioctl and display the results. This program must be written, compiled, and kept in sync with the module you're testing. On the other hand, the driver's code is easier than what is needed to implement a /proc file

There are times when ioctl is the best way to get information, because it runs faster than reading /proc. If some work must be performed on the data before it's written to the screen, retrieving the data in binary form is more efficient than reading a text file. In addition, ioctl doesn't require splitting data into fragments smaller than a page.

The strace command is a powerful tool that shows all the system calls issued by a user-space program. Not only does it show the calls, but it can also show the arguments to the calls, as well as return values in symbolic form. When a system call fails, both the symbolic value of the error (e.g., ENOMEM) and the corresponding string (Out of memory) are displayed. stracehas many command-line options; the most useful of which are -t to display the time when each call is executed, -T to display the time spent in the call, -e to limit the types of calls traced, and -o to redirect the output to a file. By default, straceprints tracing information on stderr.

strace receives information from the kernel itself. This means that a program can be traced regardless of whether or not it was compiled with debugging support (the -g option to gcc) and whether or not it is stripped. You can also attach tracing to a running process, similar to the way a debugger can connect to a running process and control it.

The trace information is often used to support bug reports sent to application developers, but it's also invaluable to kernel programmers. We've seen how driver code executes by reacting to system calls; strace allows us to check the consistency of input and output data of each call.

For example,the following screen dump shows the last lines of running the command strace ls /dev > /dev/scull0 :

 [...] open("/dev", O_RDONLY|O_NONBLOCK)     = 4 fcntl(4, F_SETFD, FD_CLOEXEC)         = 0 brk(0x8055000)                        = 0x8055000 lseek(4, 0, SEEK_CUR)                 = 0 getdents(4, /* 70 entries */, 3933)   = 1260 [...] getdents(4, /* 0 entries */, 3933)    = 0 close(4)                              = 0 fstat(1, {st_mode=S_IFCHR|0664, st_rdev=makedev(253, 0), ...}) = 0 ioctl(1, TCGETS, 0xbffffa5c)          = -1 ENOTTY (Inappropriate ioctl                                                      for device) write(1, "MAKEDEV\natibm\naudio\naudio1\na"..., 4096) = 4000 write(1, "d2\nsdd3\nsdd4\nsdd5\nsdd6\nsdd7"..., 96) = 96 write(1, "4\nsde5\nsde6\nsde7\nsde8\nsde9\n"..., 3325) = 3325 close(1)                              = 0 _exit(0)                              = ? 

 [...] open("/dev/scull0", O_RDONLY)           = 4 fstat(4, {st_mode=S_IFCHR|0664, st_rdev=makedev(253, 0), ...}) = 0 read(4, "MAKEDEV\natibm\naudio\naudio1\na"..., 16384) = 4000 read(4, "d2\nsdd3\nsdd4\nsdd5\nsdd6\nsdd7"..., 16384) = 3421 read(4, "", 16384)                      = 0 fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(3, 7), ...}) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(1, "   7421 /dev/scull0\n", 20)   = 20 close(4)                                = 0 _exit(0)                                = ? 

As expected, read is able to retrieve only four thousand bytes at a time, but the total amount of data is the same that was written in the previous example. It's interesting to note how retries are organized in this example, as opposed to the previous trace. wc is optimized for fast reading and thus bypasses the standard library, trying to read more data with a single system call. You can see from the read lines in the trace how wc tried to read 16 KB at a time.

Linux experts can find much useful information in the output of strace. If you're put off by all the symbols, you can limit yourself to watching how the file methods (open, read, and so on) work.

Note that "fault" doesn't mean "panic." The Linux code is robust enough to respond gracefully to most errors: a fault usually results in the destruction of the current process while the system goes on working. The system can panic, and it may if a fault happens outside of a process's context, or if some vital part of the system is compromised. But when the problem is due to a driver error, it usually results only in the sudden death of the process unlucky enough to be using the driver. The only unrecoverable damage when a process is destroyed is that some memory allocated to the process's context is lost; for instance, dynamic lists allocated by the driver through kmalloc might be lost. However, since the kernel calls the closeoperation for any open device when a process dies, your driver can release what was allocated by the open method.

We've already said that when kernel code misbehaves, an informative message is printed on the console. The next section explains how to decode and use such messages. Even though they appear rather obscure to the novice, processor dumps are full of interesting information, often sufficient to pinpoint a program bug without the need for additional testing.

Oops Messages

It's worth noting that the first enhancement introduced after version 2.0 was automatic handling of invalid address faults when moving data to and from user space. Linus chose to let the hardware catch erroneous memory references, so that the normal case (where the addresses are correct) is handled more efficiently.

An oops displays the processor status at the time of the fault, including the contents of the CPU registers, the location of page descriptor tables, and other seemingly incomprehensible information. The message is generated by printkstatements in the fault handler (arch/*/kernel/traps.c) and is dispatched as described earlier, in the section "printk".

Let's look at one such message. Here's what results from dereferencing a NULL pointer on a PC running version 2.4 of the kernel. The most relevant information here is the instruction pointer (EIP), the address of the faulty instruction.

Unable to handle kernel NULL pointer dereference at virtual address \      00000000  printing eip: c48370c3 *pde = 00000000 Oops: 0002 CPU:    0 EIP:    0010:[<c48370c3>] EFLAGS: 00010286 eax: ffffffea   ebx: c2281a20   ecx: c48370c0   edx: c2281a40 esi: 4000c000   edi: 4000c000   ebp: c38adf8c   esp: c38adf8c ds: 0018   es: 0018   ss: 0018 Process ls (pid: 23171, stackpage=c38ad000) Stack: 0000010e c01356e6 c2281a20 4000c000 0000010e c2281a40 c38ac000 \             0000010e         4000c000 bffffc1c 00000000 00000000 c38adfc4 c010b860 00000001 \             4000c000         0000010e 0000010e 4000c000 bffffc1c 00000004 0000002b 0000002b \             00000004  Call Trace: [<c01356e6>] [<c010b860>]  Code: c7 05 00 00 00 00 00 00 00 00 31 c0 89 ec 5d c3 8d b6 00 00  

This message was generated by writing to a device owned by the faulty module, a module built deliberately to demonstrate failures. The implementation of the write method of faulty.c is trivial:

  ssize_t faulty_write (struct file *filp, const char *buf, size_t count, 		loff_t *pos) {     /* make a simple fault by dereferencing a NULL pointer */     *(int *)0 = 0;     return 0; } 

As you can see, what we do here is dereference a NULL pointer. Since 0 is never a valid pointer value, a fault occurs, which the kernel turns into the oops message shown earlier. The calling process is then killed.

The faulty module has more interesting fault conditions in its read implementation:

  char faulty_buf[1024];  ssize_t faulty_read (struct file *filp, char *buf, size_t count,                       loff_t *pos) {     int ret, ret2;     char stack_buf[4];      printk(KERN_DEBUG "read: buf %p, count %li\n", buf, (long)count);     /* the next line oopses with 2.0, but not with 2.2 and later */     ret = copy_to_user(buf, faulty_buf, count);     if (!ret) return count; /* we survived */      printk(KERN_DEBUG "didn't fail: retry\n");     /* For 2.2 and 2.4, let's try a buffer overflow  */     sprintf(stack_buf, "1234567\n");     if (count > 8) count = 8; /* copy 8 bytes to the user */     ret2 = copy_to_user(buf, stack_buf, count);     if (!ret2) return count;     return ret2; } 

EIP:    0010:[<00000000>] [...] Call Trace: [<c010b860>]  Code:  Bad EIP value. 

Using klogd

A dump of the oops for faulty, as it reaches the system log, looks like this (note the decoded symbols on the EIP line and in the stack trace):

Unable to handle kernel NULL pointer dereference at virtual address \      00000000   printing eip:  c48370c3  *pde = 00000000  Oops: 0002  CPU:    0  EIP:    0010:[faulty:faulty_write+3/576]  EFLAGS: 00010286  eax: ffffffea   ebx: c2c55ae0   ecx: c48370c0   edx: c2c55b00  esi: 0804d038   edi: 0804d038   ebp: c2337f8c   esp: c2337f8c  ds: 0018   es: 0018   ss: 0018  Process cat (pid: 23413, stackpage=c2337000)  Stack: 00000001 c01356e6 c2c55ae0 0804d038 00000001 c2c55b00 c2336000 \             00000001        0804d038 bffffbd4 00000000 00000000 bffffbd4 c010b860 00000001 \             0804d038        00000001 00000001 0804d038 bffffbd4 00000004 0000002b 0000002b \             00000004 Call Trace: [sys_write+214/256] [system_call+52/56]   Code: c7 05 00 00 00 00 00 00 00 00 31 c0 89 ec 5d c3 8d b6 00 00   

The developer must exercise some care, however, to get useful information for errors that occur within loadable modules. klogd loads all of the available symbol information when it starts, and uses those symbols thereafter. If you load a module after klogd has initialized itself (usually at system boot), klogd will not have your module's symbol information. To force klogd to go out and get that information, send the klogd process a SIGUSR1 signal after your module has been loaded (or reloaded), and before you do anything that could cause it to oops.

Using ksymoops

Although ksymoops will go to files in /proc for some of its needed information, the results can be unreliable. The system, of course, will almost certainly have been rebooted between the time the oops occurs and when ksymoops is run, and the information from /proc may not match the state of affairs when the failure occurred. When possible, it is better to save copies of /proc/modules and /proc/ksyms prior to causing the oops to happen.

We urge driver developers to read the manual page for ksymoops because it is a very informative document.

The last argument on the tool's command line is the location of the oops message; if it is missing, the tool will read stdin in the best Unix tradition. The message can be recovered from the system logs with luck; in the case of a very bad crash you may end up writing it down off the screen and typing it back in (unless you were using a serial console, a nice tool for kernel developers).

If you do not provide all of the listed information explicitly, ksymoops will issue warnings. It will also issue warnings about things like loaded modules that define no symbols. A warning-free run of ksymoops is rare.

 >>EIP; c48370c3 <[faulty]faulty_write+3/20>   <===== Trace; c01356e6 <sys_write+d6/100> Trace; c010b860 <system_call+34/38> Code;  c48370c3 <[faulty]faulty_write+3/20> 00000000 <_EIP>: Code;  c48370c3 <[faulty]faulty_write+3/20>   <=====    0:   c7 05 00 00 00    movl   $0x0,0x0   <===== Code;  c48370c8 <[faulty]faulty_write+8/20>    5:   00 00 00 00 00  Code;  c48370cd <[faulty]faulty_write+d/20>    a:   31 c0             xorl   %eax,%eax Code;  c48370cf <[faulty]faulty_write+f/20>    c:   89 ec             movl   %ebp,%esp Code;  c48370d1 <[faulty]faulty_write+11/20>    e:   5d                popl   %ebp Code;  c48370d2 <[faulty]faulty_write+12/20>    f:   c3                ret     Code;  c48370d3 <[faulty]faulty_write+13/20>   10:   8d b6 00 00 00    leal   0x0(%esi),%esi Code;  c48370d8 <[faulty]faulty_write+18/20>   15:   00  

As you can see, ksymoops provides EIP and kernel stack information much like klogd does, but more precisely and in hexadecimal. You'll note that the faulty_writefunction is correctly reported to be 0x20 bytes long. This is because ksymoops reads the object file of your module and extracts all available information.

Unable to handle kernel NULL pointer dereference tsk->mm->context = 0000000000000734 tsk->mm->pgd = fffff80003499000               \|/ ____ \|/               "@'/ .. \`@"               /_| \_ _/ |_\                  \_ _U_/ ls(16740): Oops TSTATE: 0000004400009601 TPC: 0000000001000128 TNPC: 0000000000457fbc \ Y: 00800000 g0: 000000007002ea88 g1: 0000000000000004 g2: 0000000070029fb0 \ g3: 0000000000000018 g4: fffff80000000000 g5: 0000000000000001 g6: fffff8000119c000 \ g7: 0000000000000001 o0: 0000000000000000 o1: 000000007001a000 o2: 0000000000000178 \ o3: fffff8001224f168 o4: 0000000001000120 o5: 0000000000000000 sp: fffff8000119f621 \ ret_pc: 0000000000457fb4 l0: fffff800122376c0 l1: ffffffffffffffea l2: 000000000002c400 \ l3: 000000000002c400 l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000019c00 \ l7: 0000000070028cbc i0: fffff8001224f140 i1: 000000007001a000 i2: 0000000000000178 \ i3: 000000000002c400 i4: 000000000002c400 i5: 000000000002c000 i6: fffff8000119f6e1 \ i7: 0000000000410114 Caller[0000000000410114] Caller[000000007007cba4] Instruction DUMP: 01000000 90102000 81c3e008 <c0202000> \ 30680005 01000000 01000000 01000000 01000000 

Note how the instruction dump doesn't start from the instruction that caused the fault but three instructions earlier: that's because the RISC platforms execute several instructions in parallel and may generate deferred exceptions, so one must be able to look back at the last few instructions.

This is what ksymoops prints when fed with input data starting at the TSTATE line:

 >>TPC; 0000000001000128 <[faulty].text.start+88/a0>   <===== >>O7;  0000000000457fb4 <sys_write+114/160> >>I7;  0000000000410114 <linux_sparc_syscall+34/40> Trace; 0000000000410114 <linux_sparc_syscall+34/40> Trace; 000000007007cba4 <END_OF_CODE+6f07c40d/????> Code;  000000000100011c <[faulty].text.start+7c/a0> 0000000000000000 <_TPC>: Code;  000000000100011c <[faulty].text.start+7c/a0>    0:   01 00 00 00       nop  Code;  0000000001000120 <[faulty].text.start+80/a0>    4:   90 10 20 00       clr  %o0     ! 0 <_TPC> Code;  0000000001000124 <[faulty].text.start+84/a0>    8:   81 c3 e0 08       retl  Code;  0000000001000128 <[faulty].text.start+88/a0>   <=====    c:   c0 20 20 00       clr  [ %g0 ]   <===== Code;  000000000100012c <[faulty].text.start+8c/a0>   10:   30 68 00 05       b,a   %xcc, 24 <_TPC+0x24> \                         0000000001000140 <[faulty]faulty_write+0/20> Code;  0000000001000130 <[faulty].text.start+90/a0>   14:   01 00 00 00       nop  Code;  0000000001000134 <[faulty].text.start+94/a0>   18:   01 00 00 00       nop  Code;  0000000001000138 <[faulty].text.start+98/a0>   1c:   01 00 00 00       nop  Code;  000000000100013c <[faulty].text.start+9c/a0>   20:   01 00 00 00       nop  

To print the disassembled code shown we had to tell ksymoops the target file format and architecture (this is needed because the native architecture for SPARC64 user space is 32 bit). In this case, the options -t elf64-sparc -a sparc:v9 did the job.

You may complain that this call trace doesn't carry any interesting information; however, the SPARC processors don't save all the call trace on the stack: the O7 and I7 registers hold the instruction pointers of the last two calling functions, which is why they are shown near the call trace. In this case, the faulty instruction was in a function invoked by sys_write.

System Hangs

Other magic SysRq functions exist; see sysrq.txtin the Documentation directory of the kernel source for the full list. Note that magic SysRq must be explicitly enabled in the kernel configuration, and that most distributions do not enable it, for obvious security reasons. For a system used to develop drivers, however, enabling magic SysRq is worth the trouble of building a new kernel in itself. Magic SysRq must be enabled at runtime with a command like the following:

echo 1 > /proc/sys/kernel/sysrq 

Using an interactive debugger on the kernel is a challenge. The kernel runs in its own address space on the behalf of all the processes on the system. As a result, a number of common capabilities provided by user-space debuggers, such as breakpoints and single-stepping, are harder to come by in the kernel. In this section we look at several ways of debugging the kernel; each of them has advantages and disadvantages.

Using gdb

     gdb /usr/src/linux/vmlinux /proc/kcore 

The first argument is the name of the uncompressed kernel executable, not the zImage or bzImage or anything compressed.

The second argument on the gdb command line is the name of the core file. Like any file in /proc, /proc/kcore is generated when it is read. When the read system call executes in the /proc filesystem, it maps to a data-generation function rather than a data-retrieval one; we've already exploited this feature in "Using the /proc Filesystem" earlier in this chapter. kcore is used to represent the kernel "executable" in the format of a core file; it is a huge file because it represents the whole kernel address space, which corresponds to all physical memory. From within gdb, you can look at kernel variables by issuing the standard gdb commands. For example, p jiffies prints the number of clock ticks from system boot to the current time.

Numerous capabilities normally provided by gdb are not available when you are working with the kernel. For example, gdb is not able to modify kernel data; it expects to be running a program to be debugged under its own control before playing with its memory image. It is also not possible to set breakpoints or watchpoints, or to single-step through kernel functions.

When you compile the kernel with -gand run the debugger using vmlinux together with /proc/kcore, gdb can return a lot of information about the kernel internals. You can, for example, use commands such as p *module_list, p *module_list->next, and p *chrdevs[4]->fops to dump structures. To get the best out of p, you'll need to keep a kernel map and the source code handy.

The kdb Kernel Debugger

Other kernel developers, however, see an occasional use for interactive debugging tools. One such tool is the kdb built-in kernel debugger, available as a nonofficial patch from oss.sgi.com. To use kdb, you must obtain the patch (be sure to get a version that matches your kernel version), apply it, and rebuild and reinstall the kernel. Note that, as of this writing, kdb works only on IA-32 (x86) systems (though a version for the IA-64 existed for a while in the mainline kernel source before being removed).

Once you are running a kdb-enabled kernel, there are a couple of ways to enter the debugger. Hitting the Pause (or Break) key on the console will start up the debugger. kdb also starts up when a kernel oops happens, or when a breakpoint is hit. In any case, you will see a message that looks something like this:

Entering kdb (0xc1278000) on processor 1 due to Keyboard Entry [1]kdb>  

Note that just about everything the kernel does stops when kdb is running. Nothing else should be running on a system where you invoke kdb; in particular, you should not have networking turned on -- unless, of course, you are debugging a network driver. It is generally a good idea to boot the system in single-user mode if you will be using kdb.

As an example, consider a quick sculldebugging session. Assuming that the driver is already loaded, we can tell kdb to set a breakpoint in scull_read as follows:

[1]kdb> bp scull_read Instruction(i) BP #0 at 0xc8833514 (scull_read)     is enabled on cpu 1 [1]kdb> go 

The bp command tells kdb to stop the next time the kernel enters scull_read. We then type go to continue execution. After putting something into one of the sculldevices, we can attempt to read it by running cat under a shell on another terminal, yielding the following:

Entering kdb (0xc3108000) on processor 0 due to Breakpoint @ 0xc8833515 Instruction(i) breakpoint #0 at 0xc8833514 scull_read+0x1:   movl   %esp,%ebp [0]kdb> 

We are now positioned at the beginning of scull_read. To see how we got there, we can get a stack trace:

[0]kdb> bt     EBP       EIP         Function(args) 0xc3109c5c 0xc8833515  scull_read+0x1 0xc3109fbc 0xfc458b10  scull_read+0x33c255fc( 0x3, 0x803ad78, 0x1000, 0x1000, 0x804ad78) 0xbffffc88 0xc010bec0  system_call [0]kdb> 

kdb attempts to print out the arguments to every function in the call trace. It gets confused, however, by optimization tricks used by the compiler. Thus it prints five arguments for scull_read, which only has four.

Time to look at some data. The mds command manipulates data; we can query the value of the scull_devices pointer with a command like:

[0]kdb> mds scull_devices 1 c8836104: c4c125c0 .... 

Here we asked for one (four-byte) word of data starting at the location of scull_devices; the answer tells us that our device array was allocated starting at the address c4c125c0. To look at a device structure itself we need to use that address:

[0]kdb> mds c4c125c0  c4c125c0: c3785000  .... c4c125c4: 00000000  .... c4c125c8: 00000fa0  .... c4c125cc: 000003e8  .... c4c125d0: 0000009a  .... c4c125d4: 00000000  .... c4c125d8: 00000000  .... c4c125dc: 00000001  .... 

The eight lines here correspond to the eight fields in the Scull_Dev structure. Thus we see that the memory for the first device is allocated at 0xc3785000, that there is no next item in the list, that the quantum is 4000 (hex fa0) and the array size is 1000 (hex 3e8), that there are 154 bytes of data in the device (hex 9a), and so on.

kdb can change data as well. Suppose we wanted to trim some of the data from the device:

[0]kdb> mm c4c125d0 0x50 0xc4c125d0 = 0x50 

A subsequent cat on the device will now return less data than before.

The Integrated Kernel Debugger Patch

Other debugging capabilities in IKD include the kernel trace capability, which can record the paths taken through the kernel code. There are some memory debugging tools, including a leak detector and a couple of "poisoners," that can be useful in tracking down memory corruption problems.

Finally, IKD also includes a version of the kdb debugger discussed in the previous section. As of this writing, however, the version of kdb included in the IKD patch is somewhat old. If you need kdb, we recommend that you go directly to the source at oss.sgi.com for the current version.

The kgdb Patch

Setting up kgdb involves installing a kernel patch and booting the modified kernel. You need to connect the two systems with a serial cable (of the null modem variety) and to install some support files on the gdb side of the connection. The patch places detailed instructions in the file Documentation/i386/gdb-serial.txt; we won't reproduce them here. Be sure to read the instructions on debugging modules: toward the end there are some nice gdb macros that have been written for this purpose.

Kernel Crash Dump Analyzers

There are currently two crash dump analyzer patches available for Linux. Both were relatively new when this section was written, and both were in a state of flux. Rather than provide detailed information that is likely to go out of date, we'll restrict ourselves to providing an overview and pointers to where more information can be found.

LKCD is currently supported for the Intel 32-bit architecture only, and only works with swap partitions on SCSI disks.

Another crash dump facility is available from www.missioncriticallinux.com. This crash dump subsystem creates crash dump files directly in /var/dumps and does not use the swap area. That makes certain things easier, but it also means that the system will be modifying the file system while in a state where things are known to have gone wrong. The crash dumps generated are in a standard core file format, so tools like gdb can be used for post-mortem analysis. This package also provides a separate analyzer that is able to extract more information than gdb from the crash dump files.

The User-Mode Linux Port

Having a copy of the kernel running as a user-mode process brings a number of advantages. Because it is running on a constrained, virtual processor, a buggy kernel cannot damage the "real" system. Different hardware and software configurations can be tried easily on the same box. And, perhaps most significantly for kernel developers, the user-mode kernel can be easily manipulated with gdb or another debugger. After all, it is just another process. User-Mode Linux clearly has the potential to accelerate kernel development.

LTT, along with extensive documentation, can be found on the Web at www.opersys.com/LTT.

Dynamic Probes