Date: Tue, 5 Nov 2002 14:56:03 -0800 (PST) From: Nate Lawson <nate@root.org> To: Archie Cobbs <archie@dellroad.org> Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: GDB auto enter/detach patch Message-ID: <Pine.BSF.4.21.0211051445160.12143-100000@root.org> In-Reply-To: <200211052101.gA5L1t3Y039774@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Nov 2002, Archie Cobbs wrote: > Nate Lawson writes: > > I've put together a patch that enables a kernel on the target machine to > > detect a GDB packet and automatically enter GDB mode. When the debugger > > detaches, it also continues execution. This speeds up debugging, > > especially when the target is in a remote location. The patch plus more > > explanation is at: > > > > http://www.root.org/~nate/freebsd/ > > Neat. A couple of comments: > > 1. I think a better abstraction of the GDB packet protocol would > be something like this: > > struct gdb_parse { > int state; /* opaque state value */ > u_int len; /* current packet length */ > u_int maxlen; /* maximum packet length */ > u_char data[0]; /* packet data */ > }; > > extern void gdb_parse_init(struct gdb_parse *p); > extern int gdb_parse_byte(struct gdb_parse *p); > > That is, if you're doing the state machine, why not go ahead > and decode the packet data as well? The first version of the patch collected the data in a small static buffer with the idea that I'd send the command to the gdb stub once it was assembled. However, gdb on attach retries multiple times with different commands before giving up so I just discard the first complete gdb frame and let the retries hit gdb once I call breakpoint() > 2. You need to handle the escape mechanism for packets containing > "raw" data.: '$', '#', and '~' are escaped with '~' characters > in case the the 'X' command is used. Escapes should be added but I haven't done that yet because all the commands currently used to attach to the stub don't need them. > 3. I think GDB_AUTO_DETACH should be mandatory, i.e., the current > state of affairs is a bug IMHO. I've always wondered why that wasn't the case. I'd also like to catch the $k command (kill) which is sent on typing "quit" into gdb while still attached and do something useful. Should that also restart the kernel like an explicit "detach"? > 4. Does FreeBSD use the 'O' command to send ordinary serial port output > when GDB mode is active? Haven't looked but this would be nice to > have if it's not already there. No, it uses gdb remote chat which prefixes commands with |||| > 5. Receipt of a '$' character should always reset the state, no? > (modulo the '~' escape mechanism mentioned above). Yeah, I should add this. Basically the state machine is a little lax at the moment and it's possible (although unlikely) that data transferred over the serial port could trigger a breakpoint(). It matches $ + up to 12 chars + # + [0-F] + [0-F] If you're worried about this, just use the sysctl to turn off debug.gdb_auto_enter while transferring binary data over the gdb port. Even when I implement stricter protocol matching, relying on inband signalling is inherently unreliable. If you need to debug a serial port driver, you can use a 2nd serial port. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0211051445160.12143-100000>