Re: Remote kernel debugging over Ethernet (was: interrupting the remote kernel)
On Sun, Sep 08, 2002 at 09:54:47PM -0700, Tim Gilman wrote: Sorry about this, Christian; your patches are buried in my bottomless inbox. It appears real-life has swept me off my feet. I fully don't expect to come down for a month or so (getting married in 2 weeks, honeymoon, etc), so please continue to work around my sloth. No problem at all, real life takes preference. -- christian zander [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Remote kernel debugging over Ethernet (was: interrupting the remote kernel)
On Saturday, 7 September 2002 at 10:28:27 +0200, Christian Zander wrote: On Sat, Sep 07, 2002 at 12:56:12AM -0700, Julian Elischer wrote: What I found to work well is remote GDB debugging with the UDP wrapper (ip-gdb), it responds to CTRL-C as expected. huh? do we have that? (rushes of to see it it's in ports) comes back sadly.. (where do you get it from?) Yes, Tim Gilman posted about this on freebsd-hackers earlier this year, the project has been sittling idle since, but can still be found here: http://sourceforge.net/projects/ipgdb/. I did a little bit of work on it to make it work in environments with routers; I sent a patch to Tim, but have not yet heard back. I attached this updated version as a patch that should apply cleanly against 4.5+. It will work with eepro100 adapters in my version, but adding the necessary support for other NICs is trivial. The complete patch also needs to change a few lines in gdb to make it work, this is included in the original patch, but not in the one I attached. Just by coincidence, I heard of this today from Richard Sharpe of Panasas. It seems that Tim has moved on, which is possibly why you haven't heard back from him. I'd be interested in committing this code if nobody has any objections. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Remote kernel debugging over Ethernet (was: interrupting the remote kernel)
On Sun, Sep 08, 2002 at 05:54:56PM +0930, Greg 'groggy' Lehey wrote: Just by coincidence, I heard of this today from Richard Sharpe of Panasas. It seems that Tim has moved on, which is possibly why you haven't heard back from him. I was aware of that, I had been in touch with Tim over connections dropping after a short period of time with my configuration, which I could later attribute to the lack of ARP request handling), and had sent the patch to an alternate address. I'd be interested in committing this code if nobody has any objections. I've used this wrapper quite a bit so far and found that it works well. There are a few things that would be neat to have or that need some work (e.g. exciting GDB without an explicit detach will render the target machine unresponsive, console messages are not yet forwarded, etc), but it is very useful nevertheless. -- christian zander [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Remote kernel debugging over Ethernet (was: interrupting the remote kernel)
Christian Zander at 9/8/02 (maybe): On Sun, Sep 08, 2002 at 05:54:56PM +0930, Greg 'groggy' Lehey wrote: Just by coincidence, I heard of this today from Richard Sharpe of Panasas. It seems that Tim has moved on, which is possibly why you haven't heard back from him. I was aware of that, I had been in touch with Tim over connections dropping after a short period of time with my configuration, which I could later attribute to the lack of ARP request handling), and had sent the patch to an alternate address. Sorry about this, Christian; your patches are buried in my bottomless inbox. It appears real-life has swept me off my feet. I fully don't expect to come down for a month or so (getting married in 2 weeks, honeymoon, etc), so please continue to work around my sloth. =- Tim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupting the remote kernel
On Sat, 7 Sep 2002, Christian Zander wrote: On Fri, Sep 06, 2002 at 05:17:07PM -0700, Nate Lawson wrote: But I want to be able to pass control to the debugger when the target kernel `hangs', that is when no `ctl-alt-f1', `ctl-alt-del' has any effect. If the hang is not a system hang, the console break will have an effect. But if the kernel is so hung that the keyboard doesn't work, the remote serial console will not do you any better. In this case you need a box with a real console (i.e. Sun). What I found to work well is remote GDB debugging with the UDP wrapper (ip-gdb), it responds to CTRL-C as expected. huh? do we have that? (rushes of to see it it's in ports) comes back sadly.. (where do you get it from?) -- christian zander [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupting the remote kernel
On Sat, Sep 07, 2002 at 12:56:12AM -0700, Julian Elischer wrote:
What I found to work well is remote GDB debugging with the UDP
wrapper (ip-gdb), it responds to CTRL-C as expected.
huh? do we have that?
(rushes of to see it it's in ports)
comes back sadly..
(where do you get it from?)
Yes, Tim Gilman posted about this on freebsd-hackers earlier this
year, the project has been sittling idle since, but can still be
found here: http://sourceforge.net/projects/ipgdb/. I did a little
bit of work on it to make it work in environments with routers; I
sent a patch to Tim, but have not yet heard back. I attached this
updated version as a patch that should apply cleanly against 4.5+.
It will work with eepro100 adapters in my version, but adding the
necessary support for other NICs is trivial. The complete patch
also needs to change a few lines in gdb to make it work, this is
included in the original patch, but not in the one I attached.
--
christian zander
[EMAIL PROTECTED]
Binary files 4.5/compile/DEBUG/kernel.debug and sys/compile/DEBUG/kernel.debug differ
diff -ruN 4.5/conf/files sys/conf/files
--- 4.5/conf/files Tue Mar 26 02:12:22 2002
+++ sys/conf/files Sat Jun 22 17:14:38 2002
@@ -523,6 +523,10 @@
i4b/layer4/i4b_l4mgmt.coptional i4b
i4b/layer4/i4b_l4timer.c optional i4b
#
+# UDP wrapper for serial GDB stub
+#
+ipgdb/ipgdb.c optional ip_gdb
+#
isofs/cd9660/cd9660_bmap.c optional cd9660
isofs/cd9660/cd9660_lookup.c optional cd9660
isofs/cd9660/cd9660_node.c optional cd9660
diff -ruN 4.5/conf/options sys/conf/options
--- 4.5/conf/optionsTue Feb 19 15:08:49 2002
+++ sys/conf/optionsSat Jun 22 17:01:49 2002
@@ -63,6 +63,10 @@
DDB
DDB_UNATTENDED opt_ddb.h
GDB_REMOTE_CHATopt_ddb.h
+
+IP_GDB opt_ip_gdb.h
+IP_GDB_FXP opt_ip_gdb_fxp.h
+
HW_WDOG
KTRACE
LIBICONV
diff -ruN 4.5/dev/fxp/if_fxp.c sys/dev/fxp/if_fxp.c
--- 4.5/dev/fxp/if_fxp.cMon Feb 11 15:22:43 2002
+++ sys/dev/fxp/if_fxp.cSat Jun 22 17:08:56 2002
@@ -77,6 +77,8 @@
#include dev/fxp/if_fxpvar.h
#include dev/fxp/rcvbundl.h
+#include opt_ip_gdb_fxp.h
+
MODULE_DEPEND(fxp, miibus, 1, 1, 1);
#include miibus_if.h
@@ -169,7 +171,12 @@
static int fxp_suspend(device_t dev);
static int fxp_resume(device_t dev);
-static voidfxp_intr(void *xsc);
+#ifdef IP_GDB_FXP
+voidfxp_intr(void *xsc);
+#else
+static void fxp_intr(void *xsc);
+#endif
+
static voidfxp_intr_body(struct fxp_softc *sc,
u_int8_t statack, int count);
@@ -1179,7 +1186,11 @@
/*
* Process interface interrupts.
*/
+#ifdef IP_GDB_FXP
+void
+#else
static void
+#endif
fxp_intr(void *xsc)
{
struct fxp_softc *sc = xsc;
diff -ruN 4.5/i386/i386/i386-gdbstub.c sys/i386/i386/i386-gdbstub.c
--- 4.5/i386/i386/i386-gdbstub.cWed Aug 2 17:54:41 2000
+++ sys/i386/i386/i386-gdbstub.cThu Jun 20 16:01:29 2002
@@ -102,8 +102,11 @@
#include setjmp.h
+#include ipgdb/ipgdb.h
+
#include sio.h
#include opt_ddb.h
+#include opt_ip_gdb.h
void gdb_handle_exception (db_regs_t *, int, int);
@@ -489,13 +492,22 @@
*ptr++ = 0;
+#ifdef IP_GDB
+ ipgdb_putpacket_add_wrapper (remcomOutBuffer);
+#else
putpacket (remcomOutBuffer);
+#endif
while (1)
{
remcomOutBuffer[0] = 0;
+#ifdef IP_GDB
+ ipgdb_getpacket (remcomInBuffer);
+#else
getpacket (remcomInBuffer);
+#endif
+
switch (remcomInBuffer[0])
{
case '?':
@@ -506,7 +518,12 @@
break;
case 'D': /* detach; say OK and turn off gdb */
+#ifdef IP_GDB
+ ipgdb_putpacket_add_wrapper(remcomOutBuffer);
+ ipgdb_connected = 0;
+#else
putpacket(remcomOutBuffer);
+#endif
boothowto = ~RB_GDB;
return;
@@ -608,11 +625,17 @@
raw_regs-tf_ds = registers.ds;
raw_regs-tf_es = registers.es;
return;
-
+ /* default: */
+ /* if we don't recognize a packet, reply with empty packet */
} /* switch */
/* reply to the request */
+#ifdef IP_GDB
+ ipgdb_putpacket_add_wrapper (remcomOutBuffer);
+#else
putpacket (remcomOutBuffer);
+#endif
}
}
#endif /* NSIO 0 */
+
diff -ruN 4.5/ipgdb/ipgdb.c sys/ipgdb/ipgdb.c
--- 4.5/ipgdb/ipgdb.c Wed Dec 31 16:00:00 1969
+++ sys/ipgdb/ipgdb.c Sat Jun 22 17:40:59 2002
@@ -0,0 +1,712 @@
+/*
+ * Copyright (c) 2002
+ * Panasas, Inc. All rights reserved.
+ *
+ * Some of this code is derived from FreeBSD sources. See Copyright
+ * below.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the
Re: interrupting the remote kernel
On Sep 07 at 09:47, Christian Zander spoke: What I found to work well is remote GDB debugging with the UDP wrapper (ip-gdb), it responds to CTRL-C as expected. Is there a description available about how to configure/setup the target kernel? Where is ip-gdb available? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupting the remote kernel
On Sep 06 at 17:17, Nate Lawson spoke: You can do this by connecting a second serial cable for a console between your host and target or by using the remotechat option and a single cable. Once you have the serial console, option ALT_BREAK_TO_DEBUGGER allows you to initiate a break using your terminal emulator's send break command. My remote host is a laptop with only one sio port. So if it would be possible with a single serial connection I'd appreciate it. I have played a little with remotechat but with strange results. If I set remotechat before `target remote /dev/cuaa0' the latter fails. If I set remotechat after `target remote' but before continuing ctl-alt-esc on the target host doesn't work anymore. Only garbage appears in the remote gdb. Also ctl-c in gdb doesn't achieve anything. Only after three ctl-cs I can detach gdb. I have now also added option ALT_BREAK_TO_DEBUGGER but that doesn't help either nor does the sequence CR~^b in gdb. (I want to interrupt the target host while X is active.) If the hang is not a system hang, the console break will have an effect. But if the kernel is so hung that the keyboard doesn't work, the remote serial console will not do you any better. In this case you need a box with a real console (i.e. Sun). I won't by a Sun. I'm just hoping the hang is not a system hang. :-) -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
interrupting the remote kernel
Hello, I have BREAK_TO_DEBUGGER, DDB and no DDB_UNATTENDED on the target kernel and remotebreak = 1 on the remote gdb. So I'm expecting pressing ctl-C in the remote gdb should interrupt the remote kernel as if it had encountered a breakpoint. Is my expectation right? Nothing happens when pressing ctl-C once. Pressing it twice just gives me the option to detach gdb. How can I interrupt the remote kernel without breakpoints? I'm trying to locate kernel hangings. Is it possible with this approach? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupting the remote kernel
hit CTL_ALT_ESC on it's keyboard... or do: sysctl debug.enter_debugger=gdb On Fri, 6 Sep 2002, Hanspeter Roth wrote: Hello, I have BREAK_TO_DEBUGGER, DDB and no DDB_UNATTENDED on the target kernel and remotebreak = 1 on the remote gdb. So I'm expecting pressing ctl-C in the remote gdb should interrupt the remote kernel as if it had encountered a breakpoint. Is my expectation right? Nothing happens when pressing ctl-C once. Pressing it twice just gives me the option to detach gdb. How can I interrupt the remote kernel without breakpoints? I'm trying to locate kernel hangings. Is it possible with this approach? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupting the remote kernel
On Sep 06 at 12:11, Julian Elischer spoke: hit CTL_ALT_ESC on it's keyboard... Doing this on the remote host (running gdb) tells me `No debugger in kernel'. Doing this on the target host passes control to the remote gdb. But I want to pass control to the remote debugger by issuing the interrupt command on the _remote_ host (in gdb). or do: sysctl debug.enter_debugger=gdb Doing this on the target host also passes control to the remote gdb. But I want to be able to pass control to the debugger when the target kernel `hangs', that is when no `ctl-alt-f1', `ctl-alt-del' has any effect. I thought that remotebreak on the remote gdb should allow me this. But it seems to be something else... -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupting the remote kernel
On Fri, 6 Sep 2002, Hanspeter Roth wrote: On Sep 06 at 12:11, Julian Elischer spoke: hit CTL_ALT_ESC on it's keyboard... Doing this on the remote host (running gdb) tells me `No debugger in kernel'. Doing this on the target host passes control to the remote gdb. Like it should. Julian's suggestions were both for the target host. But I want to pass control to the remote debugger by issuing the interrupt command on the _remote_ host (in gdb). You can do this by connecting a second serial cable for a console between your host and target or by using the remotechat option and a single cable. Once you have the serial console, option ALT_BREAK_TO_DEBUGGER allows you to initiate a break using your terminal emulator's send break command. But I want to be able to pass control to the debugger when the target kernel `hangs', that is when no `ctl-alt-f1', `ctl-alt-del' has any effect. If the hang is not a system hang, the console break will have an effect. But if the kernel is so hung that the keyboard doesn't work, the remote serial console will not do you any better. In this case you need a box with a real console (i.e. Sun). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
