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? > > 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 The error "E22" is probably coming from here (gdb_cmd_query() is not expecting a "qTStatus" request): 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': // remcon_in_buffer contains: qTStatus#49 // so remcom_in_buffer + 17 is random data // so the resulting ks->threadid is a random value ptr = remcom_in_buffer + 17 kgdb_hex2long(&ptr, &ks->threadid) if (!getthread(ks->linux_regs, ks->threadid)) // EINVAL is 22, error_packet() changes -22 to 22 error_packet(remcom_out_buffer, -EINVAL) > trace API error 0x2. -Frank ------------------------------------------------------------------------------ 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
