How tp print msgs to GDB client window from GDB Server?

RE: How tp print msgs to GDB client window from GDB Server?

cross-complied gdb doesn't work with add-symbol-file (tested with 6.5, 6.8 and CVS)

hi,

I am trying to cross-compile gdb to debug Linux kernel module with
kgdb support. The host is Mac Leopard and the target machine is x86_64
Linux.

After building the crosstool chain the gdb 6.5 coming from
http://www.kegel.com/crosstool/, I tried several different gdb, 6.5,
6.8 and the latest CVS gdb.

BTW, the simple.ko is from linux kernel driver edition 3, which is
compiled with -O0 -ggdb3.

Your comments will be highly appreciated!

> /Users/cjia/downloads/gdb-6.5/gdb/gdb vmlinux
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-apple-darwin9.4.0
--target=x86_64-unknown-linux-gnu"...
(gdb) target remote udp:192.168.1.102:6443
warning: The remote protocol may be unreliable over UDP.
Some events may be lost, rendering further debugging impossible.
Remote debugging using udp:192.168.1.102:6443
breakpoint () at kernel/kgdb.c:1772
1772            atomic_set(&kgdb_setting_breakpoint, 0);
warning: shared library handler failed to enable breakpoint
(gdb) add-symbol-file ../ldd3_code/simple/simple.ko 0xffffffff883ab000
-s .data 0xffffffff883ac100 -s .bss 0xffffffff883ae600
add symbol table from file "../ldd3_code/simple/simple.ko" at
        .text_addr = 0x883ab000
        .data_addr = 0x883ac100
        .bss_addr = 0x883ae600
(y or n) y
Reading symbols from
/Users/cjia/workareas/linux_kernels/ldd3_code/simple/simple.ko...done.
(gdb) b simple_vma_
simple_vma_close   simple_vma_nopage  simple_vma_open
(gdb) b simple_vma_open
Breakpoint 1 at 0xffffffff883ab084: file include/linux/clocksource.h, line 108.
(gdb)

With the gdb 6.8 release version: ( this looks more promising at least
it didn't point to a header file anymore.)

> /Users/cjia/Downloads/gdb-6.8/gdb/gdb vmlinux
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i386-apple-darwin9.4.0
--target=x86_64-unknown-linux-gnu"...
(gdb) target remote udp:192.168.1.102:6443
warning: The remote protocol may be unreliable over UDP.
Some events may be lost, rendering further debugging impossible.
Remote debugging using udp:192.168.1.102:6443
breakpoint () at kernel/kgdb.c:1772
1772            atomic_set(&kgdb_setting_breakpoint, 0);
(gdb) add-symbol-file ../ldd3_code/simple/simple.ko 0xffffffff883ab000
-s .data 0xffffffff883ac100 -s .bss 0xffffffff883ae600
add symbol table from file "../ldd3_code/simple/simple.ko" at
        .text_addr = 0x883ab000
        .data_addr = 0x883ac100
        .bss_addr = 0x883ae600
(y or n) y
Reading symbols from
/Users/cjia/workareas/linux_kernels/ldd3_code/simple/simple.ko...done.
(gdb) b simple_vma_open
Breakpoint 1 at 0xffffffff883ab084
(gdb)

gdb from CVS:

> /Users/cjia/Downloads/gdb-6.8/gdb/gdb vmlinux
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i386-apple-darwin9.4.0
--target=x86_64-unknown-linux-gnu"...
(gdb) target remote udp:192.168.1.102:6443
warning: The remote protocol may be unreliable over UDP.
Some events may be lost, rendering further debugging impossible.
Remote debugging using udp:192.168.1.102:6443
breakpoint () at kernel/kgdb.c:1772
1772            atomic_set(&kgdb_setting_breakpoint, 0);
(gdb) add-symbol-file ../ldd3_code/simple/simple.ko 0xffffffff883ab000
-s .data 0xffffffff883ac100 -s .bss 0xffffffff883ae600
add symbol table from file "../ldd3_code/simple/simple.ko" at
        .text_addr = 0x883ab000
        .data_addr = 0x883ac100
        .bss_addr = 0x883ae600
(y or n) y
Reading symbols from
/Users/cjia/workareas/linux_kernels/ldd3_code/simple/simple.ko...done.
(gdb) b simple_vma_open
Breakpoint 1 at 0xffffffff883ab084
(gdb)

--

-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!

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

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

Sorry, re-send with plain-text.

Thanks,
Neo

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
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!

wine multi process debugging

please cc me I'm not suscribed to the mailing list                                                 

Hi,                                                                                                

I'm trying to debug a simple console program running under wine, the                               
problem is that gdb freezes when wine creates a new process, I'm using                             
follow-fork-mode child and detach-on-fork off, I've even tried to put a                            
catchpoint at the fork and attach a new instance of gdb to the new                                 
process but it can't be attached even as root, thanks for you help.                                

I'm using debian lenny with linux 2.6.21.1, gdb 6.7.1-debian and                                   
wine-1.0                                                                                           

--                                                                                                 
Avi                

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

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 <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
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!!!)

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 <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.
>>
>> Thanks,
>> Neo
>>
>> 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
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!

Memory dump

Hello folks,

My multithreded C++ program uses a large amount of memory, but there are no
memory leaks.
I tried to find memory leaks using valgrind, but it couldn't find any.
Now, I'm trying to dump the memory used by my program to find out what part
of my program uses this amount of memory.
gdb provieds a command "dump [format] memory filename start_addr end_addr"
to save the memory into a file.
My question is:
How can I find the starting and the end address of multithreaded C++
program?

Thank you in advance.
Yaser
--

-- 
View this message in context: http://www.nabble.com/Memory-dump-tp18572266p18572266.html
Sent from the Gnu - gdb - General mailing list archive at Nabble.com.

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

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 <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.
>
> Thanks,
> Neo
>
> 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.
>>>
>>> Thanks,
>>> Neo
>>>
>>> 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
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!