Skip site navigation (1)Skip section navigation (2)
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>