Hi
First of all, sorry for my mistake. I should wrote "gdb symbol table"
instead of just "symbol table". Luckily, I mentioned about that -g, so
at least you might get the idea what I was talking at that moment. Now
let's continue
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.map
c0354644 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 uL
We 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".
I hope that recipe is correct. feel free to try that....
NB: Could you please summarize our discussion and put it up on Wiki?
regards,
Mulyadi
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
