Citando Frank Rowand <frowand.l...@gmail.com>:
> On 10/9/2014 7:51 AM, joaoandrefe...@sapo.pt wrote:
>> Citando Frank Rowand <frowand.l...@gmail.com>:
>>> On 10/8/2014 3:24 PM, joaoandrefe...@sapo.pt wrote:
>
> < snip >
>
>>
>> Disclaimer #1: Yes, it seems my copy-pasted output is all messed up.
>> I don't know if it was my tiredness or just Firefox, unfortunately
>> I've just delayed even more my work.
>
> It happens. Life sucks. We move on.
>
>
>>
>> Disclaimer #2: I wasn't running anything on the target, so the last
>> example would never work. Sorry also for that. Because your previous
>> examples (before you started debugging with kdmx) relied on 3
>> different windows on the host, I wasn't accurate enough to completely
>> understand your last example.
>
>
>> Now, I've connected on the target to
>> its serial port (/dev/ttyS0), through PuTTY.
>
> Does this mean you are running PuTTY on the host system, connected
> to the /dev/ttyS0 on the host system?
>
> Do not run PuTTY. You are running minicom to access the console.
> When you run PuTTY on the host, connected to the host /dev/ttyS0,
> then there are two programs reading from /dev/ttyS0: PuTTY and
> kdmx. The data coming across the cable will be split between
> the two programs, some goint to PuTTY and some going to kdmx.
> kdmx does not get all of the traffic that is supposed to go to
> kgdb, so kgdb gets rather confused.
I'm running PuTTY on the target system, i. e., on the other side of
the host's serial cable. Regarding your scheme, in a previous message:
---------------------- HOST --------------------------------------
--- TARGET ---
terminal <----> /dev/pty/29 <----> +------+
emulator | |
| kdmx | <----> serial port
<== cable ==> target console
gdb <---------> /dev/pty/53 <----> | | /dev/ttyUSB0
+------+
I'm running PuTTY on the TARGET (scheme), as the "target console".
Maybe this is not what is supposed to happen, but it was the idea I
got from your previous email. If it isn't PuTTY, what should be? A
normal Linux terminal? Minicom? By the way, prior to that email of
yours, I had the target system simply running the OS "normally", idle,
without anything "special" running to acknowledge the serial
connection (and even before that I had the kgdbwait option set, so the
kernel stopped booting and expected a connection from GDB).
>
>> The "kgdb: Waiting for
>> connection from remote gdb..." message was of course the target
>> hanged up on boot because of the kgdbwait boot kernel option, which I
>> have removed.
>>
>> Also, regarding your questions:
>>
>>> Is the target console on the target serial port?
>>
>>> Is there a shell connected to the target serial port?
>>
>> What I've done is what I've explained above, so I can't seem to
>> differentiate both questions. I have the port open in PuTTY, and
>> that's all. Should I have minicom running on the target also? Sorry,
>> all of this is kind of new for me...
>>
>> I've just recreated that last example again. Details below:
>>
>> 1.1 - First, run kdmx with "./kdmx -n -d -p/dev/ttyS0 -b115200 -DtT":
>
> If my hints in this email do not work, then please change "-DtT" to -DsS
> for step 1.1. And also send me the kernel command line that prints on
> the console near the beginning of the boot messages of the target.
>
I've changed the option in step 1.1. Now I have:
1.1 - "./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS"
serial port: /dev/ttyS0
Initalizing the serial port to 115200 8n1
/dev/pts/3 is slave pty for for terminal emulator
/dev/pts/4 is slave pty for gdb
1.2 - "minicom -o -w -p /dev/pts/3"
1.3 - @ GDB: "set remotebaud 115200"
1.4 - Typed @ minicom: "echo g >/proc/sysrq-trigger <enter>"1.1 -
"./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS"
serial port: /dev/ttyS0
Initalizing the serial port to 115200 8n1
/dev/pts/3 is slave pty for for terminal emulator
/dev/pts/4 is slave pty for gdb
1.2 - "minicom -o -w -p /dev/pts/3"
1.3 - @ GDB: "set remotebaud 115200"
1.4 - Typed @ minicom: "echo g >/proc/sysrq-trigger <enter>"
@ kdmx: s> echo g >/proc/sysrq-trigger 0x0d
@ PuTTY (on target system): echo g>/proc/sysrq-trigger
2 - target remote /dev/pts/4
[@ GDB]:
Remote debugging using /dev/pts/4
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Malformed response to offset query, timeout
[@ kdmx]:
+$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25---+$Hg0#df$Hg0#df$Hg0#df$Hg0#df---+$?#3f$?#3f$?#3f$?#3f---+$Hc-1#09$Hc-1#09$Hc-1#09$Hc-1#09---+$qC#b4$qC#b4$qC#b4$qC#b4---+$qAttached#8f$qAttached#8f$qAttached#8f$qAttached#8f---+$qOffsets#4b$qOffsets#4b$qOffsets#4b$qOffsets#4b---+read()
of gdb pty returned
EIO,
closing and re-opening gdb pty.
EIO is expected if gdb closed the connection.
/dev/pts/4 is slave pty for gdb
gdb slave pty path is unchanged
[@ the PuTTY console, on the target system, basically almost the same
output as on kdmx]:
+$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25---+$Hg0#df$Hg0#df$Hg0#df$Hg0#df---+$?#3f$?#3f$?#3f$?#3f---+$Hc-1#09$Hc-1#09$Hc-1#09$Hc-1#09---+$qC#b4$qC#b4$qC#b4$qC#b4---+$qAttached#8f$qAttached#8f$qAttached#8f$qAttached#8f---+$qOffsets#4b$qOffsets#4b$qOffsets#4b$qOffsets#4b
3 - Typed again @ minicom: «echo "target runningagain" <enter>»
@ kdmx: echo "target runningagain" 0x0d
@ putty, target machine: echo "target runningagain"
@ kdmx: s> echo g >/proc/sysrq-trigger 0x0d
@ PuTTY (on target system): echo g>/proc/sysrq-trigger
2 - target remote /dev/pts/4
[@ GDB]:
Remote debugging using /dev/pts/4
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Malformed response to offset query, timeout
[@ kdmx]:
+$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25---+$Hg0#df$Hg0#df$Hg0#df$Hg0#df---+$?#3f$?#3f$?#3f$?#3f---+$Hc-1#09$Hc-1#09$Hc-1#09$Hc-1#09---+$qC#b4$qC#b4$qC#b4$qC#b4---+$qAttached#8f$qAttached#8f$qAttached#8f$qAttached#8f---+$qOffsets#4b$qOffsets#4b$qOffsets#4b$qOffsets#4b---+read()
of gdb pty returned
EIO,
closing and re-opening gdb pty.
EIO is expected if gdb closed the connection.
/dev/pts/4 is slave pty for gdb
gdb slave pty path is unchanged
[@ the PuTTY console, on the target system, basically almost the same
output as on kdmx]:
+$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25---+$Hg0#df$Hg0#df$Hg0#df$Hg0#df---+$?#3f$?#3f$?#3f$?#3f---+$Hc-1#09$Hc-1#09$Hc-1#09$Hc-1#09---+$qC#b4$qC#b4$qC#b4$qC#b4---+$qAttached#8f$qAttached#8f$qAttached#8f$qAttached#8f---+$qOffsets#4b$qOffsets#4b$qOffsets#4b$qOffsets#4b
3 - Typed again @ minicom: «echo "target runningagain" <enter>»
@ kdmx: echo "target runningagain" 0x0d
@ putty, target machine: echo "target runningagain"
>>
>> serial port: /dev/ttyS0
>> Initalizing the serial port to 115200 8n1
>> /dev/pts/2 is slave pty for for terminal emulator
>> /dev/pts/3 is slave pty for gdb
>>
>> 1.2 - Then, ran minicom with "minicom -o -w -p /dev/pts/2"
>>
>> 1.3 - After that, ran GDB and than "set remotebaud 115200"
>>
>> 1.4 - Typed @ minicom: "echo g >/proc/sysrq-trigger <enter>"
>>
>> t> echo g >/proc/sysrq-trigger 0x0d
>
>> [also, on the target console (PuTTY)]: echo g>/proc/sysrq-trigger
>
> This shows PuTTY capturing console output that needs to go to kdmx.
>
>>
>> 2 - Then, in GDB: "target remote /dev/pts/3"
>>
>> Remote debugging using /dev/pts/3
>> Ignoring packet error, continuing...
>> warning: unrecognized item "timeout" in "qSupported" response
>> Ignoring packet error, continuing...
>> Ignoring packet error, continuing...
>> Ignoring packet error, continuing...
>> Ignoring packet error, continuing...
>> Ignoring packet error, continuing...
>> Ignoring packet error, continuing...
>> Malformed response to offset query, timeout
>
>> [also, on the target console, a lot of characters]
>
> Those characters should be the target kernel responding to the
> requests from gdb.
>
> "the target console" is PuTTY, running on the host?
PuTTY is running on the target system, i.e. the kernel that I intend
to debug (please see your scheme reproduced above).
>
>>
>> 3 - Again in minicom: "echo "target running again" <enter>"
>>
>> echo "target running again" 0x0d
>> [also, on the target console, after the characters from point 2]:
>> echo "target running again"
>
>>
>> Conclusion: So, if I'm not wrong, it seems to work till a certain
>> point, where after GDB displayed "Remote debugging using /dev/pts/3"
>> it does display some errors and then it times out. However, it does
>> echo what is typed in minicom, both in the target PuTTY and on kdmx.
>> But it should be echoing twice in kdmx, isn't it? This is rather
>> strange, and I didn't totally understood if my minicom is running
>> properly, because I can't see neither what I type there (only in
>> kdmx, with the debugging options enabled) nor any output, although
>> this last case could not be minicom's "fault", of course (it can be
>> the target).
>>
>> Thank you so much, again! João
>>
------------------------------------------------------------------------------
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
