I am using gdb version 6.8-1, running on an x86-64 platform with
kernel version 2.6.26-2-686
(it's a Debian distrubtion) to debug a remote MIPS kernel, 2.6.22. I
have built the gdb on the
x86 machine, using the configuration parameter
--target=mipsel-unknown-linux-gnu.
After loading the kernel modules on the remote mips machine, I get the
module load addresses
from /proc/modules on the remote machine, and try to add them to the
gdb's symbol table on
the local machine, using the command:
add-symbol-file {path to local copy of the remote machine's .ko file}
{module load address retreived from remote machine's
/proc/modules}
After I do this, I can see that .text symbols are translated correctly
to their memory address on the
remote machine.
But sumbols from the .bss and .data sections are NOT translated
properly. In fact, the translate to
addresses that are not even in the range of addresses valid for the kernel.
Since then, I tried calculating which sections are loaded from the
.ko, and where each section gets
loaded into kernel memory (I put print statements in the remote
kernel's kernel/modules.c source file).
If I then give add-symbol-file the address of every loaded section,
then I get properly translated
symbols for .data and .bss.
I have noticed that the address caluclation code in gdb's symfile.c is
similar to but different from
that in the kernel's module.c file.
I am suspecting that the MIPS compiler tools are producing .ko files
that are different enough in
some way to confuse gdb's code in symbfile.c.
Has anyone else encountered this, or have any suggestions? As a work
around, I'm planning to
write a utility with code stolen from kernel/modules.c that will
calculate for me the section addresses
based on the module loading address. But it would be nice if gdb did
that calculation for me,
as I suspect it would for an x86 system.
Any suggestions?
Thanks!
Dave
