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) Message-ID: <19971228133310.31340@lemis.com> In-Reply-To: <199712280240.NAA02918@godzilla.zeta.org.au>; from Bruce Evans on Sun, Dec 28, 1997 at 01:40:10PM %2B1100 References: <199712280240.NAA02918@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971228133310.31340>