Subject: Re: remote GDB of kernel
To: Laine Stump <email@example.com>
From: Greg Oster <firstname.lastname@example.org>
Date: 12/06/1999 16:18:56
Laine Stump writes:
> At 02:18 PM 12/6/99 -0600, Greg Oster wrote:
> >"who knows". I've seen occassional sillyness with this too, esp. when
> >to get it all working for the first time.
> Actually, I've been getting frustrated by the "n" command taking up to 30
> sec. or so to complete sometimes (and other times completing immediately),
Ummm.... 'n' is for 'next', right? So it'll step 'over' any functions (and
those functions may take a long or short time to complete). How fast/slow
it responds will depend on what it has to do :)
> so I just turned on remotedebug. It looks like sometime commands aren't
> properly received by the other end, but the "-" which is supposed to
> indicate a NACK is instead interpreted as "Junk: -" (and even that only
> after a *very* long delay). It seems like the retransmission timeouts need
Hmmmm.... this might be more of a problem...
> to be tightened up quite a lot (or at least it needs to properly interpret
> the NACK character (-)). That could do a lot towards making the experience
> more enjoyable. Even though I'm only running at 9600bps (how do you set gdb
> to go faster anyway? change /etc/ttys? Or would I have to doctor the serial
> driver to change its default?)
Bump the speed in /etc/ttys, and in your kernel config.
> and my cable has all the pins connected, it
> seems like just about half of my commands need retransmission.
That's weird... I find it totally usable at 9600bps... (ya, some stuff is a
bit slow, but it's not at all like you describe..)