how to debug loadable kernel modules with gdb -- looking for help
Robert P. J. Day
rpjday at crashcourse.ca
Thu Jul 8 14:10:28 UTC 2010
i'm once again going to ask this list for help with a specific
kernel debugging issue since i've been fighting with this for a while
and am still baffled.
to set the stage, here's a column i wrote a while back at linux.com
on how to use gdb for kernel and module debugging:
if you find it useful, help yourself -- it's how to use regular gdb to
debug both kernel symbols and data objects in your running kernel and
loadable modules. and that column was perfectly fine when i tested it
all on a 32-bit system back then. but now that i'm trying it all over
again on my 64-bit ubuntu box, weird things are happening and i
suspect it's only because there are some 64-bit gdb issues of which i
so if anyone wants to educate themselves with that column, here's
where i'm running into trouble.
first, on a 32-bit system, if you want to print the current value of
jiffies, it would be
(gdb) p jiffies_64
and as my column explains, in order to update that value, you need to
(gdb) core-file /proc/kcore
that doesn't work on my 64-bit ubuntu system, where i run
(gdb) p __jiffies (the symbol i can see in /proc/kallsyms)
but it *always* prints the same value, even after reloading the core
file. any reason for that?
second, when you run "add-symbol-file" to add the symbol table for a
loaded module, you *must* specify the address of the .text section.
but on this system, there *is* no .text section as there used to be.
this is a trivially simple module with only an entry and exit routine
so, theoretically, there's no text left. in the older 32-bit system,
a similar module would still have a .text section. nowadays on this
box, no. what am i supposed to put there?
finally, i faked out "add-symbol-file" by giving it the alleged text
address of the .exit.text section since i didn't care about digging
into that section, then added the arg for the data section so i could
dump my module's variables. and that didn't work well.
even though i could see the addresses match what was in
/proc/kallsyms, i could run (in the 64-bit case):
(gdb) whatis rpjday_2
type = int
(gdb) p rpjday_2
Cannot access memory at address 0xffffffffa007c0b4
i can verify that the address of that variable is correct, the
"whatis" command gets the type correct, but gdb can't print its
contents, as i could back in the 32-bit days.
is there some single, fundamental issue i'm overlooking, perhaps in
the initial kernel configuration? are there additional issues when
using gdb on a 64-bit system? thanks for any help.
Robert P. J. Day Waterloo, Ontario, CANADA
Top-notch, inexpensive online Linux/OSS/kernel courses
More information about the ubuntu-users