Pages

04 July 2007

I put it on my blog, so at least some people could have the alternative place instead of digging kernelnewbies archieves. This is a raw summary of discussion between me and Robert P.J. Day. First, an extensive explanation from Robert:

ok, here's what i've learned so far, and i have to admit, a littleof it surprises me. to explain what i'm doing, i've just started towrite a tutorial on kernel debugging for one of my clients, and i'mtrying to start with the absolutely simplest possible techniques.

the simplest method i know of is just

# gdb vmlinux /proc/kcore

AFAIK, unless you have at least the kernel image, there's not much youcan do (but if there is, feel free to fill me in and i'll add it to mylist).

so, as a first attempt, i used the latest git tree and explicitlyconfigured *without* the DEBUG_INFO selection. even though LDD3 (p.100) claims that you need that option to have symbol information,that's not entirely true.

once i configured and built my kernel, i then had my vmlinux fileand my System.map file, and i rebooted under that new kernel. i couldthen compare the contents of System.map to the contents of/proc/kallsyms, just to verify that it looked sane:

so even eithout selecting DEBUG_INFO, you can still examine atleast *basic* data objects. what DEBUG_INFO gives you (as i read it)is the ability to dump more complicated objects, like structures. buteven without that feature, gdb is still moderately useful.

i had always read that you absolutely needed DEBUG_INFO to use gdbin any useful way, but it's clear that that's not true.

> ok, here's what i've learned so far, and i have to admit, a little> of it surprises me. to explain what i'm doing, i've just started to> write a tutorial on kernel debugging for one of my clients, and i'm> Instead of "debugging" in its true meaning (dumping values, setting breakpoint, observing stack frames, and so on), if you just use gdb that way (without using kgdb, kdb and etc) we can only dump variables, or possibly anything that just related to passive observation.

And one thing (I just tested moment ago), seems like gdb "caches" the result of "print" command. This is probably related to the fact that kcore is dynamically changed but gdb only check the value of the startup stage. So, "jiffies" or any other dynamic variables seems constant.

> trying to start with the absolutely simplest possible techniques.>> the simplest method i know of is just>> # gdb vmlinux /proc/kcore>> AFAIK, unless you have at least the kernel image, there's not much you> can do (but if there is, feel free to fill me in and i'll add it to my> list).>> $ grep jiffies /boot/System.mapc0354644 B jiffies^^^^^convert that value to decimal, because AFAIK dd can not accept offset in hexadecimal form.

$ dd if=/dev/kmem skip=3224716868 bs=1 count=4 | od -t uLWe fetch 4 bytes, since jiffies (not jiffies64) is an unsigned long variable. We tell od to display it as unsigned long as well.

For more about this kind of technique, google for "kernel memory forensics".