Home Products Documentation Wiki Support Download Showroom Contact us Where to buy
The information on this page is nolonger maintained.
For current product information visit the new Axis Developer web site on www.axis.com/products/dev/
For current developer information visit the Axis Developer WIKI
  » Documentation  » Documentation » GDB » Kernel debugging

Documentation

Overview

GDB

Overview

 

Installing GDB

Installation

Graphical UIs

 

Debugging

User mode apps

Shared libraries

Core dumps

Threads

Kernel debugging

 

Reference docs

GDB

GDB server

CRIS specific commands

 

Known problems

 

 

Download section

Download

 

Debugging The Linux 2.4 Kernel

To be able to debug the Linux 2.4 kernel, you need to enable the kgdb support in the kernel configuration, and select a suitable debug port, and then rebuild the kernel (with 'make images' for example). Note that when you enable the kgdb support, the Linux kernel will be built with -g and so may increase significantly in size. When you boot, something like this should show up on the serial port (use sermon or some other serial sniffer):

Uncompressing Linux...

Done. Now booting the kernel.

$O4c696e75782076657273696f#e3$O6e20322e342e3220286f726a616e66#81 
[lots more]

The garbled stuff is the gdb stub dumping information ($ start a packet, # ends the packet, and then there's a 2 hex digit checksum). Now start gdb-cris with the vmlinux file as argument:

gdb-cris vmlinux

Then

(gdb) target remote /dev/ttyS0

Remote debugging using /dev/ttyS0

breakpoint () at kgdb.c:1530

1530 __asm__ volatile ("break 8"); /* Jump to handle_breakpoint. */

(gdb)

A quick backtrace will tell you where you are:

(gdb) backtrace

#0 breakpoint () at kgdb.c:1530

#1 0x6004a8ca in init_IRQ () at irq.c:487

#2 0x600bc49c in start_kernel () at init/main.c:535

A couple of things to remember when debugging the kernel:

  • Turn off the watchdog (make menuconfig, under General setup). It will bite you otherwise.
  • The kernel is compiled with the -O2 flag. The compiler is likely to have rearranged the statements in the code, and variables may have been optimized away.
  • The Linux kernel contains many inlined functions, multi-statement macros and assembly code. Be prepared to disassemble to really understand what's going on.
  • Things happen under your feet. For example, interrupts caused by the timer occur while you are debugging.
  • Some parts of the code don't really like being stepped through, like the somewhat critical stack frame setup in entry.S.
© Axis Communications, All Rights Reserved.

Contact  | Axis Sites  | Privacy Statement