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

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

[Neo Jia]

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!

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

[Michael Snyder]

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!

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

[Neo Jia]

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!

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

[Neo Jia]

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!