gdb symbol problem

gdb symbol problem

[Hushan Jia]

Hi, I compiled the code with -g -ggdb flags, but it seems gdb cannot
show symbols
correctly, instead it shows all ??

Remote debugging using /dev/pts/11
0xc0467118 in ?? ()
(gdb) where
#0  0xc0467118 in ?? ()
#1  0xc077db2d in ?? ()
#2  0x00000000 in ?? ()

how to solve this problem?

-- 
Thanks & Regards,
Hushan Jia

Re: gdb symbol problem

[Paul Pluzhnikov]

On Tue, Dec 22, 2009 at 8:47 PM, Hushan Jia <hushan.jia@gmail.com> wrote:
> Hi, I compiled the code with -g -ggdb flags, but it seems gdb cannot
> show symbols
> correctly, instead it shows all ??
>
> Remote debugging using /dev/pts/11
> 0xc0467118 in ?? ()
> (gdb) where
> #0  0xc0467118 in ?? ()
> #1  0xc077db2d in ?? ()
> #2  0x00000000 in ?? ()
>
> how to solve this problem?

It might help for you to provide your complete GDB session, from
invocation to the "failing" where command.
My crystal ball tells me you didn't supply GDB with the executable you
are running.

Cheers,
-- 
Paul Pluzhnikov

Re: gdb symbol problem

[Hushan Jia]

On Sat, Dec 26, 2009 at 4:55 PM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> On Tue, Dec 22, 2009 at 8:47 PM, Hushan Jia <hushan.jia@gmail.com> wrote:
>> Hi, I compiled the code with -g -ggdb flags, but it seems gdb cannot
>> show symbols
>> correctly, instead it shows all ??
>>
>> Remote debugging using /dev/pts/11
>> 0xc0467118 in ?? ()
>> (gdb) where
>> #0  0xc0467118 in ?? ()
>> #1  0xc077db2d in ?? ()
>> #2  0x00000000 in ?? ()
>>
>> how to solve this problem?
>
> It might help for you to provide your complete GDB session, from
> invocation to the "failing" where command.
I invoke gdb like this:

[hushan@hushan-t linux-2.6.31.3]$ 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 "i686-pc-linux-gnu"...
(gdb) set remotebaud 115200
(gdb) target remote /dev/pts/5
(gdb) Remote debugging using /dev/pts/11
0xc0467118 in ?? ()
(gdb) where
#0  0xc0467118 in ?? ()
#1  0xc077db2d in ?? ()
#2  0x00000000 in ?? ()


> My crystal ball tells me you didn't supply GDB with the executable you
> are running.
>
> Cheers,
> --
> Paul Pluzhnikov
>



-- 
Thanks & Regards,
Hushan Jia

Re: gdb symbol problem

[Paul Pluzhnikov]

On Sat, Dec 26, 2009 at 6:16 PM, Hushan Jia <hushan.jia@gmail.com> wrote:

> I invoke gdb like this:
>
> [hushan@hushan-t linux-2.6.31.3]$ gdb ./vmlinux

Oh, you are not debugging a regular application. You probably should
have mentioned that in your initial message.

> (gdb) target remote /dev/pts/5

What is on the "other end" of /dev/pts/5 ?

>> My crystal ball tells me you didn't supply GDB with the executable you
>> are running.

My crystal ball now tells me that you are stopped in a loadable kernel
module. AFAIU, GDB has no way to automatically find what is loaded
where in the target kernel.

You might want to read:
http://sourceforge.net/projects/kgdb-light/
http://sourceware.org/ml/gdb/2009-01/msg00037.html

Cheers,
-- 
Paul Pluzhnikov

Re: gdb symbol problem

[Hushan Jia]

On Sun, Dec 27, 2009 at 11:36 AM, Paul Pluzhnikov
<ppluzhnikov@google.com> wrote:
> On Sat, Dec 26, 2009 at 6:16 PM, Hushan Jia <hushan.jia@gmail.com> wrote:
>
>> I invoke gdb like this:
>>
>> [hushan@hushan-t linux-2.6.31.3]$ gdb ./vmlinux
>
> Oh, you are not debugging a regular application. You probably should
> have mentioned that in your initial message.

Sorry for forget the important information.

>
>> (gdb) target remote /dev/pts/5
>
> What is on the "other end" of /dev/pts/5 ?

Hi, the other end is console output redirected from qemu emulator, I
have added "kgdboc=ttyS0,115200 kgdbwait" parameter to the kernel.

>
>>> My crystal ball tells me you didn't supply GDB with the executable you
>>> are running.
>
> My crystal ball now tells me that you are stopped in a loadable kernel
> module. AFAIU, GDB has no way to automatically find what is loaded
> where in the target kernel.

Remote debugging using /dev/pts/11
0xc0467118 in ?? ()

above message is output when I connected to pts initially, and the
kernel is waiting for remote gdb's connect, so I dont think it is in a
module.

>
> You might want to read:
> http://sourceforge.net/projects/kgdb-light/
> http://sourceware.org/ml/gdb/2009-01/msg00037.html
>
> Cheers,
> --
> Paul Pluzhnikov
>



-- 
Thanks & Regards,
Hushan Jia

Re: gdb symbol problem

[Jie Zhang]

On 12/27/2009 11:45 AM, Hushan Jia wrote:
> On Sun, Dec 27, 2009 at 11:36 AM, Paul Pluzhnikov
> <ppluzhnikov@google.com>  wrote:
>> On Sat, Dec 26, 2009 at 6:16 PM, Hushan Jia<hushan.jia@gmail.com>  wrote:
>>
>>> I invoke gdb like this:
>>>
>>> [hushan@hushan-t linux-2.6.31.3]$ gdb ./vmlinux
>>
>> Oh, you are not debugging a regular application. You probably should
>> have mentioned that in your initial message.
>
> Sorry for forget the important information.
>
What's the output of "readelf -S vmlinux"?


Jie

Re: gdb symbol problem

[Hushan Jia]

On Mon, Dec 28, 2009 at 10:38 AM, Jie Zhang <jie.zhang@analog.com> wrote:
> On 12/27/2009 11:45 AM, Hushan Jia wrote:
>>
>> On Sun, Dec 27, 2009 at 11:36 AM, Paul Pluzhnikov
>> <ppluzhnikov@google.com>  wrote:
>>>
>>> On Sat, Dec 26, 2009 at 6:16 PM, Hushan Jia<hushan.jia@gmail.com>  wrote:
>>>
>>>> I invoke gdb like this:
>>>>
>>>> [hushan@hushan-t linux-2.6.31.3]$ gdb ./vmlinux
>>>
>>> Oh, you are not debugging a regular application. You probably should
>>> have mentioned that in your initial message.
>>
>> Sorry for forget the important information.
>>
> What's the output of "readelf -S vmlinux"?

Hi, The output is:

# readelf -S vmlinux
There are 77 section headers, starting at offset 0x3b569cc:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text.head        PROGBITS        c1000000 001000 0000a9 00  AX  0   0  4
  [ 2] .rel.text.head    REL             00000000 3b575d4 000070 08
 75   1  4
  [ 3] .text             PROGBITS        c10000c0 0010c0 291284 00  AX  0   0 32
  [ 4] .rel.text         REL             00000000 3b57644 0c08f0 08
 75   3  4
  [ 5] __ex_table        PROGBITS        c1291350 292350 000fa8 00   A  0   0 16
  [ 6] .rel__ex_table    REL             00000000 3c17f34 001d78 08
 75   5  4
  [ 7] .rodata           PROGBITS        c1293000 294000 133f54 00   A  0   0 32
  [ 8] .rel.rodata       REL             00000000 3c19cac 05e620 08
 75   7  4
  [ 9] __bug_table       PROGBITS        c13c6f58 3c7f58 003f24 00   A  0   0  1
  [10] .rel__bug_table   REL             00000000 3c782cc 005430 08
 75   9  4
  [11] .pci_fixup        PROGBITS        c13cae7c 3cbe7c 000b38 00   A  0   0  4
  [12] .rel.pci_fixup    REL             00000000 3c7d6fc 000b38 08
 75  11  4
  [13] .builtin_fw       PROGBITS        c13cb9b4 3cc9b4 000090 00   A  0   0  4
  [14] .rel.builtin_fw   REL             00000000 3c7e234 0000c0 08
 75  13  4
  [15] __ksymtab         PROGBITS        c13cba44 3cca44 005ba8 00   A  0   0  4
  [16] .rel__ksymtab     REL             00000000 3c7e2f4 00b750 08
 75  15  4
  [17] __ksymtab_gpl     PROGBITS        c13d15ec 3d25ec 002890 00   A  0   0  4
  [18] .rel__ksymtab_gpl REL             00000000 3c89a44 005120 08
 75  17  4
  [19] __kcrctab         PROGBITS        c13d3e7c 3d4e7c 002dd4 00   A  0   0  4
  [20] .rel__kcrctab     REL             00000000 3c8eb64 005ba8 08
 75  19  4
  [21] __kcrctab_gpl     PROGBITS        c13d6c50 3d7c50 001448 00   A  0   0  4
  [22] .rel__kcrctab_gpl REL             00000000 3c9470c 002890 08
 75  21  4
  [23] __ksymtab_strings PROGBITS        c13d8098 3d9098 0126ab 00   A  0   0  1
  [24] __init_rodata     PROGBITS        c13ea760 3eb760 003780 00   A  0   0 32
  [25] .rel__init_rodata REL             00000000 3c96f9c 0003e8 08
 75  24  4
  [26] __param           PROGBITS        c13edee0 3eeee0 001120 00   A  0   0  4
  [27] .rel__param       REL             00000000 3c97384 001188 08
 75  26  4
  [28] .data             PROGBITS        c13ef000 3f0000 037498 00  WA
 0   0 4096
  [29] .rel.data         REL             00000000 3c9850c 012ed8 08
 75  28  4
  [30] .init.text        PROGBITS        c1427000 428000 029c3f 00  AX  0   0  1
  [31] .rel.init.text    REL             00000000 3cab3e4 019d70 08
 75  30  4
  [32] .init.data        PROGBITS        c1450c40 451c40 020967 00  WA  0   0 32
  [33] .rel.init.data    REL             00000000 3cc5154 001750 08
 75  32  4
  [34] .init.setup       PROGBITS        c14715b0 4725b0 0008dc 00  WA  0   0  4
  [35] .rel.init.setup   REL             00000000 3cc68a4 000bd0 08
 75  34  4
  [36] .initcall.init    PROGBITS        c1471e8c 472e8c 000554 00  WA  0   0  4
  [37] .rel.initcall.ini REL             00000000 3cc7474 000aa8 08
 75  36  4
  [38] .con_initcall.ini PROGBITS        c14723e0 4733e0 000008 00  WA  0   0  4
  [39] .rel.con_initcall REL             00000000 3cc7f1c 000010 08
 75  38  4
  [40] .x86_cpu_dev.init PROGBITS        c14723e8 4733e8 00001c 00   A  0   0  4
  [41] .rel.x86_cpu_dev. REL             00000000 3cc7f2c 000038 08
 75  40  4
  [42] .security_initcal PROGBITS        c1472404 473404 000004 00  WA  0   0  4
  [43] .rel.security_ini REL             00000000 3cc7f64 000008 08
 75  42  4
  [44] .altinstructions  PROGBITS        c1472408 473408 003be7 00   A  0   0  4
  [45] .rel.altinstructi REL             00000000 3cc7f6c 004fe0 08
 75  44  4
  [46] .altinstr_replace PROGBITS        c1475fef 476fef 000f4e 00  AX  0   0  1
  [47] .rel.altinstr_rep REL             00000000 3cccf4c 000038 08
 75  46  4
  [48] .exit.text        PROGBITS        c1476f3d 477f3d 000de6 00  AX  0   0  1
  [49] .rel.exit.text    REL             00000000 3cccf84 000e38 08
 75  48  4
  [50] .init.ramfs       PROGBITS        c1478000 479000 000200 00   A  0   0  1
  [51] .data.percpu      PROGBITS        c1479000 47a000 00a2dc 00  WA
 0   0 4096
  [52] .rel.data.percpu  REL             00000000 3ccddbc 000030 08
 75  51  4
  [53] .smp_locks        PROGBITS        c1484000 485000 006000 00   A  0   0  4
  [54] .rel.smp_locks    REL             00000000 3ccddec 00af80 08
 75  53  4
  [55] .bss              NOBITS          c148a000 48b000 0b9b74 00  WA
 0   0 4096
  [56] .brk              NOBITS          c1544000 48b000 125000 00  WA  0   0  1
  [57] .comment          PROGBITS        00000000 48b000 00cc7c 00      0   0  1
  [58] .debug_aranges    PROGBITS        00000000 497c80 00c290 00      0   0  8
  [59] .rel.debug_arange REL             00000000 3cd8d6c 007cc0 08
 75  58  4
  [60] .debug_pubnames   PROGBITS        00000000 4a3f10 042264 00      0   0  1
  [61] .rel.debug_pubnam REL             00000000 3ce0a2c 002380 08
 75  60  4
  [62] .debug_info       PROGBITS        00000000 4e6174 2d12647 00
  0   0  1
  [63] .rel.debug_info   REL             00000000 3ce2dac 147dfc0 08
  75  62  4
  [64] .debug_abbrev     PROGBITS        00000000 31f87bb 14652a 00
  0   0  1
  [65] .debug_line       PROGBITS        00000000 333ece5 29597c 00
  0   0  1
  [66] .rel.debug_line   REL             00000000 5160d6c 003fd8 08
 75  65  4
  [67] .debug_frame      PROGBITS        00000000 35d4664 095fa0 00
  0   0  4
  [68] .rel.debug_frame  REL             00000000 5164d44 046040 08
 75  67  4
  [69] .debug_str        PROGBITS        00000000 366a604 123fab 01
MS  0   0  1
  [70] .debug_loc        PROGBITS        00000000 378e5af 3376f1 00
  0   0  1
  [71] .rel.debug_loc    REL             00000000 51aad84 243820 08
 75  70  4
  [72] .debug_ranges     PROGBITS        00000000 3ac5ca0 090a98 00
  0   0  1
  [73] .rel.debug_ranges REL             00000000 53ee5a4 090d30 08
 75  72  4
  [74] .shstrtab         STRTAB          00000000 3b56738 000291 00
  0   0  1
  [75] .symtab           SYMTAB          00000000 547f2d4 0adf20 10
 76 30275  4
  [76] .strtab           STRTAB          00000000 552d1f4 0eb2f9 00
  0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

>
>
> Jie
>



-- 
Thanks & Regards,
Hushan Jia

Re: gdb symbol problem

[Jie Zhang]

On 12/28/2009 12:14 PM, Hushan Jia wrote:
> On Mon, Dec 28, 2009 at 10:38 AM, Jie Zhang<jie.zhang@analog.com>  wrote:
>> On 12/27/2009 11:45 AM, Hushan Jia wrote:
>>>
>>> On Sun, Dec 27, 2009 at 11:36 AM, Paul Pluzhnikov
>>> <ppluzhnikov@google.com>    wrote:
>>>>
>>>> On Sat, Dec 26, 2009 at 6:16 PM, Hushan Jia<hushan.jia@gmail.com>    wrote:
>>>>
>>>>> I invoke gdb like this:
>>>>>
>>>>> [hushan@hushan-t linux-2.6.31.3]$ gdb ./vmlinux
>>>>
>>>> Oh, you are not debugging a regular application. You probably should
>>>> have mentioned that in your initial message.
>>>
>>> Sorry for forget the important information.
>>>
>> What's the output of "readelf -S vmlinux"?
>
> Hi, The output is:
>
> # readelf -S vmlinux
> There are 77 section headers, starting at offset 0x3b569cc:
>
> Section Headers:
>    [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>    [ 0]                   NULL            00000000 000000 000000 00      0   0  0
>    [ 1] .text.head        PROGBITS        c1000000 001000 0000a9 00  AX  0   0  4
>    [ 2] .rel.text.head    REL             00000000 3b575d4 000070 08
>   75   1  4
>    [ 3] .text             PROGBITS        c10000c0 0010c0 291284 00  AX  0   0 32

It seems the machine was not executing code of your vmlinux. The code in 
your vmlinux starts from 0xc1000000. But when you connected with GDB, 
the stopped PC was 0xc0467118, which was just ahead of code sections of 
your vmlinux. Is it possbile the linux kernel running in your qemu was 
not the one you told GDB?


Jie

Re: gdb symbol problem

[Jie Zhang]

On 12/28/2009 01:09 PM, Hushan Jia wrote:
> On Mon, Dec 28, 2009 at 12:21 PM, Jie Zhang<jie.zhang@analog.com>  wrote:
>> On 12/28/2009 12:14 PM, Hushan Jia wrote:
>>>
>>> On Mon, Dec 28, 2009 at 10:38 AM, Jie Zhang<jie.zhang@analog.com>    wrote:
>>>>
>>>> On 12/27/2009 11:45 AM, Hushan Jia wrote:
>>>>>
>>>>> On Sun, Dec 27, 2009 at 11:36 AM, Paul Pluzhnikov
>>>>> <ppluzhnikov@google.com>      wrote:
>>>>>>
>>>>>> On Sat, Dec 26, 2009 at 6:16 PM, Hushan Jia<hushan.jia@gmail.com>
>>>>>>   wrote:
>>>>>>
>>>>>>> I invoke gdb like this:
>>>>>>>
>>>>>>> [hushan@hushan-t linux-2.6.31.3]$ gdb ./vmlinux
>>>>>>
>>>>>> Oh, you are not debugging a regular application. You probably should
>>>>>> have mentioned that in your initial message.
>>>>>
>>>>> Sorry for forget the important information.
>>>>>
>>>> What's the output of "readelf -S vmlinux"?
>>>
>>> Hi, The output is:
>>>
>>> # readelf -S vmlinux
>>> There are 77 section headers, starting at offset 0x3b569cc:
>>>
>>> Section Headers:
>>>    [Nr] Name              Type            Addr     Off    Size   ES Flg Lk
>>> Inf Al
>>>    [ 0]                   NULL            00000000 000000 000000 00      0
>>>    0  0
>>>    [ 1] .text.head        PROGBITS        c1000000 001000 0000a9 00  AX  0
>>>    0  4
>>>    [ 2] .rel.text.head    REL             00000000 3b575d4 000070 08
>>>   75   1  4
>>>    [ 3] .text             PROGBITS        c10000c0 0010c0 291284 00  AX  0
>>>    0 32
>>
>> It seems the machine was not executing code of your vmlinux. The code in
>> your vmlinux starts from 0xc1000000. But when you connected with GDB, the
>> stopped PC was 0xc0467118, which was just ahead of code sections of your
>> vmlinux. Is it possbile the linux kernel running in your qemu was not the
>> one you told GDB?
>
> Hi, I compiled the kernel on the host machine, and then copy kernel
> and modules files to the qemu virtual machine, they are the same
> files.

OK. Then you need to find out what's at the address 0xc0467118. GDB 
cannot show you the symbol and source line which it doesn't know. 
/proc/kallsyms might be helpful if that address is in kernel.

> and the kgdb seems does not work, if I run c in gdb, then I cannot
> interrupt it using CTRL-C, and the breakpoints are never hit.
> The attached file is the kernel config, and kernel is
> linux-2.6.31.3.tar.bz2, downloaded from kernel.org.
>
I have no idea about kgdb.


Jie

Re: gdb symbol problem

[Hui Zhu]

Maybe your address is a part of a LKM.
If so, find it out with "cat /proc/modules", and use gdb cmd
"add-symbol-file module_dir_name address" add symbol message to gdb.

Hui

On Mon, Dec 28, 2009 at 14:38, Jie Zhang <jie.zhang@analog.com> wrote:
> On 12/28/2009 01:09 PM, Hushan Jia wrote:
>>
>> On Mon, Dec 28, 2009 at 12:21 PM, Jie Zhang<jie.zhang@analog.com>  wrote:
>>>
>>> On 12/28/2009 12:14 PM, Hushan Jia wrote:
>>>>
>>>> On Mon, Dec 28, 2009 at 10:38 AM, Jie Zhang<jie.zhang@analog.com>
>>>>  wrote:
>>>>>
>>>>> On 12/27/2009 11:45 AM, Hushan Jia wrote:
>>>>>>
>>>>>> On Sun, Dec 27, 2009 at 11:36 AM, Paul Pluzhnikov
>>>>>> <ppluzhnikov@google.com>      wrote:
>>>>>>>
>>>>>>> On Sat, Dec 26, 2009 at 6:16 PM, Hushan Jia<hushan.jia@gmail.com>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> I invoke gdb like this:
>>>>>>>>
>>>>>>>> [hushan@hushan-t linux-2.6.31.3]$ gdb ./vmlinux
>>>>>>>
>>>>>>> Oh, you are not debugging a regular application. You probably should
>>>>>>> have mentioned that in your initial message.
>>>>>>
>>>>>> Sorry for forget the important information.
>>>>>>
>>>>> What's the output of "readelf -S vmlinux"?
>>>>
>>>> Hi, The output is:
>>>>
>>>> # readelf -S vmlinux
>>>> There are 77 section headers, starting at offset 0x3b569cc:
>>>>
>>>> Section Headers:
>>>>   [Nr] Name              Type            Addr     Off    Size   ES Flg
>>>> Lk
>>>> Inf Al
>>>>   [ 0]                   NULL            00000000 000000 000000 00
>>>>  0
>>>>   0  0
>>>>   [ 1] .text.head        PROGBITS        c1000000 001000 0000a9 00  AX
>>>>  0
>>>>   0  4
>>>>   [ 2] .rel.text.head    REL             00000000 3b575d4 000070 08
>>>>  75   1  4
>>>>   [ 3] .text             PROGBITS        c10000c0 0010c0 291284 00  AX
>>>>  0
>>>>   0 32
>>>
>>> It seems the machine was not executing code of your vmlinux. The code in
>>> your vmlinux starts from 0xc1000000. But when you connected with GDB, the
>>> stopped PC was 0xc0467118, which was just ahead of code sections of your
>>> vmlinux. Is it possbile the linux kernel running in your qemu was not the
>>> one you told GDB?
>>
>> Hi, I compiled the kernel on the host machine, and then copy kernel
>> and modules files to the qemu virtual machine, they are the same
>> files.
>
> OK. Then you need to find out what's at the address 0xc0467118. GDB cannot
> show you the symbol and source line which it doesn't know. /proc/kallsyms
> might be helpful if that address is in kernel.
>
>> and the kgdb seems does not work, if I run c in gdb, then I cannot
>> interrupt it using CTRL-C, and the breakpoints are never hit.
>> The attached file is the kernel config, and kernel is
>> linux-2.6.31.3.tar.bz2, downloaded from kernel.org.
>>
> I have no idea about kgdb.
>
>
> Jie
>

Re: gdb symbol problem

[Hushan Jia]

On Mon, Dec 28, 2009 at 3:36 PM, Hui Zhu <teawater@gmail.com> wrote:
> Maybe your address is a part of a LKM.
> If so, find it out with "cat /proc/modules", and use gdb cmd
> "add-symbol-file module_dir_name address" add symbol message to gdb.
>
> Hui
>
> On Mon, Dec 28, 2009 at 14:38, Jie Zhang <jie.zhang@analog.com> wrote:
>> On 12/28/2009 01:09 PM, Hushan Jia wrote:
>>>
>>> On Mon, Dec 28, 2009 at 12:21 PM, Jie Zhang<jie.zhang@analog.com>  wrote:
>>>>
>>>> On 12/28/2009 12:14 PM, Hushan Jia wrote:
>>>>>
>>>>> On Mon, Dec 28, 2009 at 10:38 AM, Jie Zhang<jie.zhang@analog.com>
>>>>>  wrote:
>>>>>>
>>>>>> On 12/27/2009 11:45 AM, Hushan Jia wrote:
>>>>>>>
>>>>>>> On Sun, Dec 27, 2009 at 11:36 AM, Paul Pluzhnikov
>>>>>>> <ppluzhnikov@google.com>      wrote:
>>>>>>>>
>>>>>>>> On Sat, Dec 26, 2009 at 6:16 PM, Hushan Jia<hushan.jia@gmail.com>
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> I invoke gdb like this:
>>>>>>>>>
>>>>>>>>> [hushan@hushan-t linux-2.6.31.3]$ gdb ./vmlinux
>>>>>>>>
>>>>>>>> Oh, you are not debugging a regular application. You probably should
>>>>>>>> have mentioned that in your initial message.
>>>>>>>
>>>>>>> Sorry for forget the important information.
>>>>>>>
>>>>>> What's the output of "readelf -S vmlinux"?
>>>>>
>>>>> Hi, The output is:
>>>>>
>>>>> # readelf -S vmlinux
>>>>> There are 77 section headers, starting at offset 0x3b569cc:
>>>>>
>>>>> Section Headers:
>>>>>   [Nr] Name              Type            Addr     Off    Size   ES Flg
>>>>> Lk
>>>>> Inf Al
>>>>>   [ 0]                   NULL            00000000 000000 000000 00
>>>>>  0
>>>>>   0  0
>>>>>   [ 1] .text.head        PROGBITS        c1000000 001000 0000a9 00  AX
>>>>>  0
>>>>>   0  4
>>>>>   [ 2] .rel.text.head    REL             00000000 3b575d4 000070 08
>>>>>  75   1  4
>>>>>   [ 3] .text             PROGBITS        c10000c0 0010c0 291284 00  AX
>>>>>  0
>>>>>   0 32
>>>>
>>>> It seems the machine was not executing code of your vmlinux. The code in
>>>> your vmlinux starts from 0xc1000000. But when you connected with GDB, the
>>>> stopped PC was 0xc0467118, which was just ahead of code sections of your
>>>> vmlinux. Is it possbile the linux kernel running in your qemu was not the
>>>> one you told GDB?
>>>
>>> Hi, I compiled the kernel on the host machine, and then copy kernel
>>> and modules files to the qemu virtual machine, they are the same
>>> files.
>>
>> OK. Then you need to find out what's at the address 0xc0467118. GDB cannot
>> show you the symbol and source line which it doesn't know. /proc/kallsyms
>> might be helpful if that address is in kernel.
>>
>>> and the kgdb seems does not work, if I run c in gdb, then I cannot
>>> interrupt it using CTRL-C, and the breakpoints are never hit.
>>> The attached file is the kernel config, and kernel is
>>> linux-2.6.31.3.tar.bz2, downloaded from kernel.org.
>>>
>> I have no idea about kgdb.
>>
>>
>> Jie
>>
>

Thanks for all your replies, the kgdb kernel cannot boot, maybe it is
a config problem.



-- 
Thanks & Regards,
Hushan Jia