Is add-symbol-files broken on 64bit? (Need help!!!)

Neo Jia neojia@gmail.com
Thu Jul 24 00:07:00 GMT 2008


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:
        `/home/cjia/scratch/workareas/linux_kernels/linux-2.6/vmlinux',
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
Quit

Any idea about this?

Thanks,
Neo

On Sun, Jul 20, 2008 at 6:53 PM, Neo Jia <neojia@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.
>
> Thanks,
> Neo
>
> On Sun, Jul 20, 2008 at 4:37 PM, Michael Snyder <msnyder@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.
>>>
>>> Thanks,
>>> Neo
>>>
>>> On Fri, Jul 18, 2008 at 1:00 AM, Neo Jia <neojia@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 loadable module.
>>> >
>>> > 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!



More information about the Gdb mailing list