Re: Is add-symbol-files broken on 64bit? (Need help!!!)
Neo Jia <neojia <at> gmail.com>
2008-07-23 09:18:23 GMT
This is the wired output from gdb after doing "info files".
(gdb) info files
Symbols from "/home/cjia/scratch/workareas/linux_kernels/linux-2.6/vmlinux".
Remote serial target in gdb-specific protocol:
Debugging a target over a serial line.
While running this, GDB does not access memory from...
Local exec file:
file type elf64-x86-64.
Entry point: 0x1000000
0xffffffff81000000 - 0xffffffff8128b4a3 is .text
0xffffffff8128b4b0 - 0xffffffff8128f260 is __ex_table
0xffffffff8128f260 - 0xffffffff8128f284 is .notes
0xffffffff8128f288 - 0xffffffff81296278 is __bug_table
0xffffffff81297000 - 0xffffffff8138c4f1 is .rodata
0xffffffff8138c500 - 0xffffffff8138d6e0 is .pci_fixup
0xffffffff8138d6e0 - 0xffffffff81397d50 is __ksymtab
0xffffffff81397d50 - 0xffffffff8139b5a0 is __ksymtab_gpl
0xffffffff8139b5a0 - 0xffffffff813afa9c is __ksymtab_strings
0xffffffff813afaa0 - 0xffffffff813b1000 is __param
0xffffffff813b1000 - 0xffffffff813ea1a8 is .data
0xffffffff813eb000 - 0xffffffff81439980 is .data.cacheline_aligned
0xffffffff81439980 - 0xffffffff8144b588 is .data.read_mostly
0xffffffffff600000 - 0xffffffffff6000ec is .vsyscall_0
0xffffffffff600100 - 0xffffffffff600131 is .vsyscall_fn
0xffffffffff600180 - 0xffffffffff6001d0 is .vsyscall_gtod_data
0xffffffffff600400 - 0xffffffffff60043c is .vsyscall_1
0xffffffffff600800 - 0xffffffffff600860 is .vsyscall_2
0xffffffffff600860 - 0xffffffffff600864 is .vgetcpu_mode
0xffffffffff600880 - 0xffffffffff600888 is .jiffies
0xffffffffff600c00 - 0xffffffffff600c0d is .vsyscall_3
0xffffffff8144e000 - 0xffffffff81450000 is .data.init_task
0xffffffff81450000 - 0xffffffff81451000 is .data.page_aligned
0xffffffff81451000 - 0xffffffff81457f08 is .smp_locks
0xffffffff81458000 - 0xffffffff8147f91b is .init.text
0xffffffff8147f920 - 0xffffffff814a12c0 is .init.data
0xffffffff814a12c0 - 0xffffffff814a2160 is .init.setup
0xffffffff814a2160 - 0xffffffff814a29c0 is .initcall.init
0xffffffff814a29c0 - 0xffffffff814a29d0 is .con_initcall.init
0xffffffff814a29d0 - 0xffffffff814a29e0 is .security_initcall.init
---Type <return> to continue, or q <return> to quit---q
Any idea about this?
On Sun, Jul 20, 2008 at 6:53 PM, Neo Jia <neojia <at> gmail.com> wrote:
> The problem is that I can use the same way to debug 32bit env. Also, I
> can see the debugging symbol and line numbers from the ko file.
> On Sun, Jul 20, 2008 at 4:37 PM, Michael Snyder <msnyder <at> specifix.com> wrote:
>> I have a vague recollection to the effect that kernel modules
>> can be debugged in somewhat the same manner as shared libraries,
>> but a quick google search didn't turn up anything very useful.
>> Never done it myself, don't know anything more specific than that.
>> On Fri, 2008-07-18 at 01:02 -0700, Neo Jia wrote:
>>> Sorry, re-send with plain-text.
>>> On Fri, Jul 18, 2008 at 1:00 AM, Neo Jia <neojia <at> gmail.com> wrote:
>>> > hi,
>>> > I am using the gdb to debug Linux kernel module on x86-64 bit with a patched kernel (kgdb). Everything
works fine for the kernel itself, I can break on any functions, and see the sources. But, I can't break on the
symbols in the kernel module after it is loaded. I used the "add-symbol-files" to add the sections for that
>>> > The same setup works fine for 32bit and I even can see the symbols/sources by running gdb directly
against the 64bit .ko file.
>>> > Any suggestions? I am struggling with this question for a long time.
>>> > Thanks,
>>> > Neo
>>> > --
>>> > I would remember that if researchers were not ambitious
>>> > probably today we haven't the technology we are using!
>>> I would remember that if researchers were not ambitious
>>> probably today we haven't the technology we are using!
> I would remember that if researchers were not ambitious
> probably today we haven't the technology we are using!
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!