From owner-freebsd-current  Sat Dec 27 19:04:18 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA10000
          for current-outgoing; Sat, 27 Dec 1997 19:04:18 -0800 (PST)
          (envelope-from owner-freebsd-current)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA09993
          for <freebsd-current@FreeBSD.ORG>; Sat, 27 Dec 1997 19:04:10 -0800 (PST)
          (envelope-from grog@lemis.com)
Received: (from grog@localhost)
          by freebie.lemis.com (8.8.8/8.8.7) id NAA07942;
          Sun, 28 Dec 1997 13:33:11 +1030 (CST)
          (envelope-from grog)
Message-ID: <19971228133310.31340@lemis.com>
Date: Sun, 28 Dec 1997 13:33:10 +1030
From: Greg Lehey <grog@lemis.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-current@FreeBSD.ORG, skynyrd@opus.cts.cwu.edu
Subject: Re: Remote gdb (was: no boot: config -g and options DDB)
References: <199712280240.NAA02918@godzilla.zeta.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <199712280240.NAA02918@godzilla.zeta.org.au>; from Bruce Evans on Sun, Dec 28, 1997 at 01:40:10PM +1100
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sun, Dec 28, 1997 at 01:40:10PM +1100, Bruce Evans wrote:
>> Well, no.  In fact, there's no evidence that ddb sets the speed at
>> all.  The gdb command just sets a flag, and when I hit the next trap I
>
> Just like fopen() doesn't set the speed.  It knows nothing of
> devices.

Yes, but fwrite() doesn't go on and talk to the device registers.  ddb
does, without first setting them.

>> I think that this is basically broken.  When ddb goes to gdb after a
>> trap, it shouldn't make any assumptions about what somebody else might
>> have done.  It should save the current UART registers, set what it
>> wants, and restore the old contents on return.  Sure, it's unlikely
>
> That's the device driver's job.  It doesn't work very well with gdb,
> since input may arrive while gdb is switched out, so you have to set
> the speed to the same value for all users of the device so that the
> context switching is null.  Non-null switching also trips over UART
> bugs.

ddb doesn't use the device driver.  It talks directly to the device
with functions like:

void
siocnputc(dev, c)
	dev_t	dev;
	int	c;
{
	int	s;
	struct siocnstate	sp;

	s = spltty();
	siocnopen(&sp);
	siocntxwait();
	outb(siocniobase + com_data, c);
	siocnclose(&sp);
	splx(s);
}

I think that's reasonable: the more of the kernel the debugger uses,
the less of the kernel you can debug with it.  But it does mean that
it should set the control registers correctly first.

I thought that maybe I need COMCONSOLE, but it's still not talking
across the serial line.

Greg