how to debug loadable kernel modules with gdb -- looking for help

[Robert P. J. Day]

  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:

http://www.linux.com/learn/linux-training/33991-the-kernel-newbie-corner-kernel-and-module-debugging-with-gdb

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
am unaware.

  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
run

  (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
  (gdb)

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.

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Top-notch, inexpensive online Linux/OSS/kernel courses
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================