Re: [Kgdb-bugreport] KGDB problem at first breakpoint

[Prabhu nath <gprabhunath@xxxxxxxxx>]

No luck. Atleast, I am interested to know, if it is working for anyone or there is a bug in kgdb implementation in the kernel. If so, I can cool off for some more days until it gets rectified. 

Thanks,
Prabhu

On Fri, May 27, 2011 at 10:06 PM, Dongdong Deng <libfetion@xxxxxxxxx> wrote:

On Fri, May 20, 2011 at 12:23 PM, Prabhu nath <gprabhunath@xxxxxxxxx> wrote:
> Enabling CONFIG_DEBUG_RODATA also didn't work.

I am sorry, the CONFIG_DEBUG_RODATA should be disabled...


Could you try to pass full parameters to kgdboc module?
"kgdboc=ttyS0,115200 kgdbwait"


Dongdong

>
> -Prabhu
>
>
> On Thu, May 19, 2011 at 6:45 AM, Dongdong Deng <libfetion@xxxxxxxxx> wrote:
>>
>> On Wed, May 18, 2011 at 7:23 PM, Prabhu nath <gprabhunath@xxxxxxxxx>
>> wrote:
>> > Dear All,
>> >
>> >       There is a problem with the KGDB at the very first break point
>> > after
>> > executing the gdb command "target remote /dev/ttyS0" from the host.
>> >       I have verbatim, followed the KGDB document
>> > http://kernel.org/pub/linux/kernel/people/jwessel/kdb/
>> >
>> > Problem Logs:
>> > ---------------------
>> >
>> > Details  of my hardware and system software:
>> > -------------------------------------------------------------------
>> >
>> > *Host (Development machine): *
>> >                      Intel Pentium IV Machine with Fedora Core 12
>> >                      Linux Version : 2.6.31.5-127.fc12.i686.PAE
>> >                      gdb version : GNU gdb (GDB) Fedora (7.0-3.fc12)
>> >
>> > *Target:*
>> >                 Intel Pentium IV Machine with Fedora Core 12
>> >                 Customized Linux Version :  2.6.38
>> >
>> > Host is connected to Target via a null modem cable
>> >
>> > *Snapshot of .config of linux version 2.6.38 on the target *
>> > *
>> > *
>> > # CONFIG_DEBUG_RODATA is not set
>>
>>
>> Hi Prabhu,
>>
>> The CONFIG_DEBUG_RODATA was suggested to set at KGDB,
>> Could you enable it?
>>
>> CONFIG_DEBUG_RODATA = y
>>
>> Dongdong
>>
>
>>
>> >
>> > CONFIG_HAVE_ARCH_KGDB=y
>> > CONFIG_FRAME_POINTER=y
>> > CONFIG_DEBUG_INFO=y
>> > CONFIG_KGDB=y
>> > CONFIG_KGDB_SERIAL_CONSOLE=y
>> > CONFIG_KGDB_LOW_LEVEL_TRAP=y
>> >
>> > *Grub config on the target machine*
>> > *
>> > *
>> > title Fedora (2.6.38)
>> >        root (hd0,0)
>> >        kernel /boot/vmlinuz-2.6.38 ro
>> > root=UUID=fb7800fb-cfe7-438d-bc7f-c153ba4353d1  LANG=en_US.UTF-8
>> > SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
>> > KEYTABLE=us*console=ttyS0,115200n8
>> > kgdboc=ttyS0 kgdbwai*t
>> >        initrd /boot/initrd-2.6.38.img
>> >
>> >
>> > On power on of the target, linux kernel boots and the logs are seen on
>> > the
>> > minicom console of the host and it will wait for the gdb on the host to
>> > connect. Here is the last 4 lines of the logs seen on the minicom
>> >
>> > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>> > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>> > 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>> > kgdb: Registered I/O driver kgdboc.
>> > kgdb: Waiting for connection from remote gdb..
>> >
>> > *--- Now I close the minicom console (Ctrl-A X) and start the gdb on the
>> > host. Here is the steps I follow. *
>> > *
>> > *
>> > *On the host machine:*
>> > *
>> > *
>> >
>> > [root@localhost kgdb]# gdb vmlinux
>> >
>> > GNU gdb (GDB) Fedora (7.0-3.fc12)
>> > Copyright (C) 2009 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-redhat-linux-gnu".
>> > For bug reporting instructions, please see:
>> > <http://www.gnu.org/software/gdb/bugs/>...
>> > Reading symbols from /root/kgdb/vmlinux...done.
>> >
>> > (gdb) set remotebaud 115200
>> > (gdb) set debug remote 1
>> > (gdb) target remote /dev/ttyS0
>> > Remote debugging using /dev/ttyS0
>> > Sending packet: $qSupported#37...Ack
>> > Packet received:
>> > Packet qSupported (supported-packets) is NOT supported
>> > Sending packet: $Hg0#df...Ack
>> > Packet received: OK
>> > Sending packet: $?#3f...Ack
>> > Packet received: S05
>> > Sending packet: $Hc-1#09...Ack
>> > Packet received: OK
>> > Sending packet: $qC#b4...Ack
>> > Packet received: QC01
>> > Sending packet: $qAttached#8f...Ack
>> > Packet received:
>> > Packet qAttached (query-attached) is NOT supported
>> > Sending packet: $qOffsets#4b...Ack
>> > Packet received:
>> > Sending packet: $g#67...Ack
>> > Packet received:
>> >
>> > 36000000ffffffff0abaffff20d98bc06c3f86de783f86de803ac8dd803f86de885747c00202000060000000680000007b00c8dd7b0086deffff0000ffff0000
>> > Sending packet: $mc0475788,1#a4...Ack
>> > Packet received: 0f
>> > Sending packet: $mc0475788,8#ab...Ack
>> > Packet received: 0faef889f6ff0d08
>> > Sending packet: $mc0475788,7#aa...Ack
>> > Packet received: 0faef889f6ff0d
>> > 0xc0475788 in ?? ()
>> > Sending packet: $qSymbol::#5b...Ack
>> > Packet received:
>> > Packet qSymbol (symbol-lookup) is NOT supported
>> > (gdb) s
>> > Cannot find bounds of current function
>> > (gdb)
>> >
>> >
>> > *Observation:*
>> >                     *1.* Ideally the kernel being debugged should break
>> > at
>> > legitimate address and the corresponding line number should
>> >                         be displayed instead of " 0xc0475788 in ?? ()".
>> >
>> >                     2. On inspecting section header in vmlinux
>> > executable,
>> > I found the .text section address range is from
>> >                         0xC1000000 to 0xC1326e58  and no section's
>> > contents
>> > associate with the address 0xC0475788.
>> >
>> >                     *3.* Hence on single stepping, gdb logs the error
>> > as* "Cannot
>> > find bounds of current function"*
>> > *
>> > *
>> >  Humbly request you to help me in addressing this issue.
>> >
>> > Thanks and Regards,
>> > Prabhu
>> >
>> > ------------------------------------------------------------------------------
>> > What Every C/C++ and Fortran developer Should Know!
>> > Read this article and learn how Intel has extended the reach of its
>> > next-generation tools to help Windows* and Linux* C/C++ and Fortran
>> > developers boost performance applications - including clusters.
>> > http://p.sf.net/sfu/intel-dev2devmay
>> > _______________________________________________
>> > Kgdb-bugreport mailing list
>> > Kgdb-bugreport@xxxxxxxxxxxxxxxxxxxxx
>> > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
>> >
>
>

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies