From owner-freebsd-hackers Fri Aug 30 13:17:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA17611 for hackers-outgoing; Fri, 30 Aug 1996 13:17:04 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA17602 for ; Fri, 30 Aug 1996 13:17:02 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id NAA08916; Fri, 30 Aug 1996 13:15:24 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) by whistle.com via smap (V1.3) id sma008908; Fri Aug 30 13:15:00 1996 Message-ID: <32274B81.446B9B3D@whistle.com> Date: Fri, 30 Aug 1996 13:13:53 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Bruce Evans CC: pst@shockwave.com, hackers@FreeBSD.org Subject: Re: gdb remote References: <199608301456.AAA07864@godzilla.zeta.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > >I don't know why yours is hellishly slow, it sounds like the tty code > >is not syncing properly or you're getting lots of retries. In addition, > >all the breakpoints and continues and steps work fine for me. > > The retries might be caused by UART bugs. sio context switches the > UART registers on every `cn' i/o so that TCIOSETA on the debugger > port can be single stepped and don't wipe out the debugger's settings. > This works OK at typing speeds but can't work for input at high speeds > unless the context switching is a no-op. Can you suggest a patch to nobble this? I have no intention of single stepping through a TCIOXXXX. wouldn't it be better to just set a bit that stops such a TCIOSETA from actually doing anything if it is set..? I'll try impliment this as a test today > There are UART bugs that > cause harmful side effects even when the context switching should be > a no-op. > > > booting -g I can get the kernel to fall into the appropriate debugger > > by hitting ctl-alt-esc on the keyboard. > > The -current gdb works here only after booting with -dg. I get checksum > errors after ctl-sysreq. same here.. works GREAT fro -gd though that's not that useful if what you need is to repond to a breakpoint...... breakpoints have the same effect as ctl-sysreq. > > > it's hellishly slow..... > > for example.. > > the folloing took 1 minute to print out.... > > (kgdb) bt > > #0 0xf01adf7d in Debugger () > > #1 0xf01caf31 in sgetc () > > #2 0xf01c6737 in pcvt_timeout () > > #3 0xf01092a4 in softclock () presently I'm getting.... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... It's hit a breakpoint but it can't get past this error so I'm eventually going to have to reboot.. > > This takes a second or two here. Still too long. 115200 bps should make > it fast enough for a command line debugger. sounds to me like you're getting errors too, the messages should take a fraction of a second.. > > Bruce