On Wed, Sep 16 2009 at 6:44pm -0400,
Bob Montgomery <bob.montgomery(a)hp.com> wrote:
This patch allows the dis -l command to show real source line
numbers
for module code, instead of this sort of thing:
crash-4.0.9> dis -l bnx2_poll_msix
include/linux/cpumask.h: 612
0xffffffffa008acc3 <bnx2_poll_msix>: push %rbp
0xffffffffa008acc4 <bnx2_poll_msix+1>: mov %rsp,%rbp
0xffffffffa008acc7 <bnx2_poll_msix+4>: push %r15
0xffffffffa008acc9 <bnx2_poll_msix+6>: push %r14
0xffffffffa008accb <bnx2_poll_msix+8>: push %r13
0xffffffffa008accd <bnx2_poll_msix+10>: mov %esi,%r13d
0xffffffffa008acd0 <bnx2_poll_msix+13>: push %r12
0xffffffffa008acd2 <bnx2_poll_msix+15>: xor %r12d,%r12d
0xffffffffa008acd5 <bnx2_poll_msix+18>: push %rbx
0xffffffffa008acd6 <bnx2_poll_msix+19>: mov %rdi,%rbx
0xffffffffa008acd9 <bnx2_poll_msix+22>: sub $0x8,%rsp
The problem has to do with a symbol table in the kernel containing an
abnormally huge text range because of a goofy vsyscall reference in the
file "arch/x86/kernel/hpet.c".
(gdb) p *(struct block *)0x8d664b0
$41 = {startaddr = 0xffffffff80225130, endaddr = 0xffffffffff6001b3,
This range pretty much covers the entire module address space and since
the kernel file is first in the object_files list, the search stops
there and returns the closest symbol from the kernel, instead of looking
on through the object list to the module of actual interest.
This patch causes the code to keep looking through all modules and
return the real best symbol thingy (you can tell how much I really know
about gdb's symtab stuff, ahem). Thanks (and blame) to John Wright for
suggesting the fix once I found the problem.
The patch applies to the gdb patch file in the crash directory.
John and I think that this code in gdb searches things too many times,
particularly with this patch, but it's a start since it seems to fix the
problem. Mayhaps some gdb experts can now help do it right.
With the patch, the above example becomes:
crash-4.0.9> dis -l bnx2_poll_msix
/build/buildd/linux-2.6-clim-2.6.29-clim/debian/build/build_amd64_none_amd64/drivers/net/bnx2.c:
3215
0xffffffffa008acc3 <bnx2_poll_msix>: push %rbp
0xffffffffa008acc4 <bnx2_poll_msix+1>: mov %rsp,%rbp
0xffffffffa008acc7 <bnx2_poll_msix+4>: push %r15
0xffffffffa008acc9 <bnx2_poll_msix+6>: push %r14
0xffffffffa008accb <bnx2_poll_msix+8>: push %r13
0xffffffffa008accd <bnx2_poll_msix+10>: mov %esi,%r13d
0xffffffffa008acd0 <bnx2_poll_msix+13>: push %r12
/build/buildd/linux-2.6-clim-2.6.29-clim/debian/build/build_amd64_none_amd64/drivers/net/bnx2.c:
3219
0xffffffffa008acd2 <bnx2_poll_msix+15>: xor %r12d,%r12d
/build/buildd/linux-2.6-clim-2.6.29-clim/debian/build/build_amd64_none_amd64/drivers/net/bnx2.c:
3215
0xffffffffa008acd5 <bnx2_poll_msix+18>: push %rbx
0xffffffffa008acd6 <bnx2_poll_msix+19>: mov %rdi,%rbx
0xffffffffa008acd9 <bnx2_poll_msix+22>: sub $0x8,%rsp
Bob Montgomery
I bisected this problem some time ago but it didn't go anywhere after
that:
http://www.redhat.com/archives/crash-utility/2009-January/msg00063.html
So your observation about arch/x86/kernel/hpet.c really makes sense.
Thanks for sorting this out Bob!!!