Hello again, By the way, while googling for this error I've noticed that a common mistake is to invoke GDB on the wrong location (e. g. http://ehc.ac/p/kgdb/mailman/message/23341685/). What I'm doing is calling GDB on /boot/ directory on the host machine, where I've placed the vmlinux file, after following these instructions: http://bipinkunal.blogspot.pt/2012/05/kgdb-tutorial.html Apart from a possible newbie mistake, I guess I'm doing it right.
Regards, João Citando joaoandrefe...@sapo.pt: > Citando Frank Rowand <frowand.l...@gmail.com>: > >> On 10/2/2014 4:29 AM, joaoandrefe...@sapo.pt wrote: >>> Hello all, >>> >>> I have two machines running CentOS connected through a serial cable. >>> The connection seems to be working since I can transmit text via PuTTY >>> in each direction. I have started KGDB in one machine, where it is >>> waiting for a connection from remote GDB. On the second machine, I've >>> started GDB with the following commands and output (please see below). >>> I don't know what is possibly going wrong, and I've tried, among other >>> sources, to look at this somewhat similar situation (although the >>> output is different: >>> http://stackoverflow.com/questions/14584504/problems-to-connect-gdb-over-an-serial-port-to-an-kgdb-build-kernel), >>> but I'm >>> having >>> no >>> luck. >>> >>> To start, I'm trying to test the connection between KGDB and GDB, any >>> help on this would be awesome. >> >> Reading between the lines, I am assuming that both host and target >> machines are x86. Is that correct? > > Yes, you're correct. Both machines are running 32 bit CentOS (I forgot > to mention that). > >> >> >>> >>> Regards & thanks for reading, >>> João >>> >>> $ sudo gdb ./vmlinux >>> [sudo] password for cloud: >>> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-64.el6_5.2) >>> Copyright (C) 2010 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 /boot/vmlinux...done. >>> (gdb) set remotebaud 115200 >>> (gdb) set debug remote 1 >>> (gdb) target remote /dev/ttyS0 >>> Remote debugging using /dev/ttyS0 >>> Sending packet: $qSupported:xmlRegisters=i386;qRelocInsn+#25...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: QC0000000000000001 >>> 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: >>> 36000000ccb59cc0000000003841Citando Frank Rowand <frowand.l...@gmail.com>: > >> On 10/2/2014 4:29 AM, joaoandrefe...@sapo.pt wrote: >>> Hello all, >>> >>> I have two machines running CentOS connected through a serial cable. >>> The connection seems to be working since I can transmit text via PuTTY >>> in each direction. I have started KGDB in one machine, where it is >>> waiting for a connection from remote GDB. On the second machine, I've >>> started GDB with the following commands and output (please see below). >>> I don't know what is possibly going wrong, and I've tried, among other >>> sources, to look at this somewhat similar situation (although the >>> output is different: >>> http://stackoverflow.com/questions/14584504/problems-to-connect-gdb-over-an-serial-port-to-an-kgdb-build-kernel), >>> but I'm >>> having >>> no >>> luck. >>> >>> To start, I'm trying to test the connection between KGDB and GDB, any >>> help on this would be awesome. >> >> Reading between the lines, I am assuming that both host and target >> machines are x86. Is that correct? > > Yes, you're correct. Both machines are running 32 bit CentOS (I forgot > to mention that). > >> >> >>> >>> Regards & thanks for reading, >>> João >>> >>> $ sudo gdb ./vmlinux >>> [sudo] password for cloud: >>> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-64.el6_5.2) >>> Copyright (C) 2010 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 /boot/vmlinux...done. >>> (gdb) set remotebaud 115200 >>> (gdb) set debug remote 1 >>> (gdb) target remote /dev/ttyS0 >>> Remote debugging using /dev/ttyS0 >>> Sending packet: $qSupported:xmlRegisters=i386;qRelocInsn+#25...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: QC0000000000000001 >>> 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: >>> 36000000ccb59cc00000000038419fc074ff06f780ff06f708f1a1c00000000019174ac09602000060000000680000007b00a1c07b000000ffff0000ffff0000 >>> kgdb_breakpoint (new_kgdb_io_ops=0xc09f4138) at kernel/kgdb.c:1721 >>> 1721 kernel/kgdb.c: No such file or directory. >>> in kernel/kgdb.c >> >> Running gdb in the root of the kernel source tree should allow it to >> find kernel/kgdb.c >> >> >>> Sending packet: $qSymbol::#5b...Ack >>> Packet received: >>> Packet qSymbol (symbol-lookup) is NOT supported >>> Sending packet: $qTStatus#49...Ack >>> Packet received: E22 >> >> Check whether gdb_cmd_query() calls error_packet(, -EINVAL) >> (see the pseudocode explanation below). The fix for that >> was commit fb82c0ff27b2, which I think was after 2.6.32.4. >> (You mentioned the kernel version in the previous thread. I >> am assuming you are still using that version.) >> >> >> kernel/debug/gdbstub.c: >> >> gdb_serial_stub() >> while (1) >> switch (remcom_in_buffer[0]) >> case 'q': /* query command */ >> gdb_cmd_query(ks) >> switch (remcom_in_buffer[1]) >> case 'T': >> if (memcmp(remcom_in_buffer + 1, "ThreadExtraInfo,", 16)) >> // used to set error to 22, fixed by fb82c0ff27b2 >> // old code was: >> error_packet(remcom_out_buffer, -EINVAL) >> // new code, after fb82c0ff27b2, is: >> break >> ptr = remcom_in_buffer + 17 >> kgdb_hex2long(&ptr, &ks->threadid) >> if (!getthread(ks->linux_regs, ks->threadid)) >> error_packet(remcom_out_buffer, -EINVAL) >> >> >> Note that commit fb82c0ff27b2 makes a similar change in >> gdb_cmd_query() for case 'f', ThreadInfo. >> >>> trace API error 0x2. >> >> -Frank > > You're right. I've found someone with the same issue, and was able to > fix it by following this thread: > http://osdir.com/ml/KGDB-linux-kernel-debug/2012-03/msg00065.html (but > mine was on /kernel/kgdb.c, because it is the stable branch). Then I > saw your answer (and btw, yes, I'm using kernel 2.6.32.4) > > After that, I've recompiled the kernel and now "trace API error 0x2" > error has gone away. However, GDB still can't find kgdb.c. The new > output is: > > $ sudo gdb ./vmlinux > GNU gdb (GDB) Red Hat Enterprise Linux (7.2-64.el6_5.2) > Copyright (C) 2010 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 /boot/vmlinux...done. > (gdb) set remotebaud 115200 > (gdb) set debug remote 1 > (gdb) target remote /dev/ttyS0 > Remote debugging using /dev/ttyS0 > Sending packet: $qSupported:xmlRegisters=i386;qRelocInsn+#25...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: QC0000000000000001 > 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: > 36000000ccb59cc00000000038419fc074ff06f780ff06f708f1a1c00000000019174ac09602000060000000680000007b00a1c07b000000ffff0000ffff0000 > kgdb_breakpoint (new_kgdb_io_ops=0xc09f4138) at kernel/kgdb.c:1718 > 1718 kernel/kgdb.c: No such file or directory. > in kernel/kgdb.c > Sending packet: $qSymbol::#5b...Ack > Packet received: > Packet qSymbol (symbol-lookup) is NOT supported > Sending packet: $qTStatus#49...Ack > Packet received: > > 9fc074ff06f780ff06f708f1a1c00000000019174ac09602000060000000680000007b00a1c07b000000ffff0000ffff0000 >>> kgdb_breakpoint (new_kgdb_io_ops=0xc09f4138) at kernel/kgdb.c:1721 >>> 1721 kernel/kgdb.c: No such file or directory. >>> in kernel/kgdb.c >> >> Running gdb in the root of the kernel source tree should allow it to >> find kernel/kgdb.c >> >> >>> Sending packet: $qSymbol::#5b...Ack >>> Packet received: >>> Packet qSymbol (symbol-lookup) is NOT supported >>> Sending packet: $qTStatus#49...Ack >>> Packet received: E22 >> >> Check whether gdb_cmd_query() calls error_packet(, -EINVAL) >> (see the pseudocode explanation below). The fix for that >> was commit fb82c0ff27b2, which I think was after 2.6.32.4. >> (You mentioned the kernel version in the previous thread. I >> am assuming you are still using that version.) >> >> >> kernel/debug/gdbstub.c: >> >> gdb_serial_stub() >> while (1) >> switch (remcom_in_buffer[0]) >> case 'q': /* query command */ >> gdb_cmd_query(ks) >> switch (remcom_in_buffer[1]) >> case 'T': >> if (memcmp(remcom_in_buffer + 1, "ThreadExtraInfo,", 16)) >> // used to set error to 22, fixed by fb82c0ff27b2 >> // old code was: >> error_packet(remcom_out_buffer, -EINVAL) >> // new code, after fb82c0ff27b2, is: >> break >> ptr = remcom_in_buffer + 17 >> kgdb_hex2long(&ptr, &ks->threadid) >> if (!getthread(ks->linux_regs, ks->threadid)) >> error_packet(remcom_out_buffer, -EINVAL) >> >> >> Note that commit fb82c0ff27b2 makes a similar change in >> gdb_cmd_query() for case 'f', ThreadInfo. >> >>> trace API error 0x2. >> >> -Frank > > You're right. I've found someone with the same issue, and was able to > fix it by following this thread: > http://osdir.com/ml/KGDB-linux-kernel-debug/2012-03/msg00065.html (but > mine was on /kernel/kgdb.c, because it is the stable branch). Then I > saw your answer (and btw, yes, I'm using kernel 2.6.32.4) > > After fixing the code, I've recompiled the kernel and now "trace API > error 0x2" error has gone away. However, GDB still can't find kgdb.c. > The new output is below. > > I'll continue my search and if I have news, I will let you know. Also, > if you have a hint on what is going on here, I'll be glad to know. > Meanwhile, I'll also look after your suggestion in the previous > thread, about using an agent-proxy. > > Thanks for all, Frank, > João > > $ sudo gdb ./vmlinux > GNU gdb (GDB) Red Hat Enterprise Linux (7.2-64.el6_5.2) > Copyright (C) 2010 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 /boot/vmlinux...done. > (gdb) set remotebaud 115200 > (gdb) set debug remote 1 > (gdb) target remote /dev/ttyS0 > Remote debugging using /dev/ttyS0 > Sending packet: $qSupported:xmlRegisters=i386;qRelocInsn+#25...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: QC0000000000000001 > 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: > 36000000ccb59cc00000000038419fc074ff06f780ff06f708f1a1c00000000019174ac09602000060000000680000007b00a1c07b000000ffff0000ffff0000 > kgdb_breakpoint (new_kgdb_io_ops=0xc09f4138) at kernel/kgdb.c:1718 > 1718 kernel/kgdb.c: No such file or directory. > in kernel/kgdb.c > Sending packet: $qSymbol::#5b...Ack > Packet received: > Packet qSymbol (symbol-lookup) is NOT supported: > Sending packet: $qTStatus#49...Ack > Packet received: > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Kgdb-bugreport mailing list > Kgdb-bugreport@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
