On Wed, Sep 16 2009 at 6:44pm -0400,
Bob Montgomery <bob.montgomery@xxxxxx> 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!!!
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
