Date: Sat, 4 Jan 2003 06:32:43 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Nate Lawson <nate@root.org> Cc: ryan beasley <ryanb@goddamnbastard.org>, <freebsd-current@FreeBSD.ORG> Subject: Re: current/stable remote gdb interoperability Message-ID: <20030104061403.G5322-100000@gamplex.bde.org> In-Reply-To: <Pine.BSF.4.21.0301031105440.98827-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Jan 2003, Nate Lawson wrote: > On Fri, 3 Jan 2003, ryan beasley wrote: > > The serial port on the -CURRENT machine is compiled at 38400. FYI, > > jesper == 4.7R-p2 debugging box, and fredrik == 5.0 panic box. This > > instance of gdb was compiled from source w/ the patches found in the > > devel/gdb52 port. (I don't have room for the ports tree locally.) > > > > The problem I'm running into is primarily erratic behavior. The trace > > trap shown below occurs frequently, and while it's only a minor > > annoyance, my main concern is gdb randomly freezing when attempting to > > get a backtrace. (Sometimes it'll run to completion, others will hang > > between frames.) > > The bt command causes a lot of serial io and so you are probably running > into problems with siointr() not being fast. Try backing down to 9600 and > see if that works. I've had a similar problem before. Everything else > you are doing seems ok. Er, the debugging machine runs 4.7, so siointr() shouldn't be broken. The debuggee machine does serial i/o using polling when in gdb, so siointr() is not involved. It's not clear if/how polled mode actually works. The debuggee may be in a loop sending; if it spends more than <size of input fifo> character times in its output look then it will miss input. The protocol may be carefully designed to limit problems, but it would be easier to poll for input and output concurrently. I don't know if the protocol is so designed; the i/o routines certainly aren't smart. I've never seen problems at 115200 bps in practice, but I rarely use gdb for kernel debugging. Another possible problem is using the same serial line for gdb as for the console and mixing speeds. If the userland speed differs from the low level speed, then the i/o routines switch back and forth between the speeds for every character and this tends to lose some. The userland speed is locked to the low level speed initially but userland unlock it. Losing a character or two is almost unnoticable in ddb but is fatal in gdb. I normally set all speeds to 115200 so I only see this problem when I look for it. Bruce 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?20030104061403.G5322-100000>