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
