From owner-freebsd-current Sat Dec 27 18:24:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07693 for current-outgoing; Sat, 27 Dec 1997 18:24:48 -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 SAA07650 for ; Sat, 27 Dec 1997 18:24:23 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id MAA06444; Sun, 28 Dec 1997 12:54:01 +1030 (CST) (envelope-from grog) Message-ID: <19971228125401.34698@lemis.com> Date: Sun, 28 Dec 1997 12:54:01 +1030 From: Greg Lehey To: Bruce Evans Cc: skynyrd@opus.cts.cwu.edu, freebsd-current@FreeBSD.ORG Subject: Re: Remote gdb (was: no boot: config -g and options DDB) References: <199712280204.NAA01965@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199712280204.NAA01965@godzilla.zeta.org.au>; from Bruce Evans on Sun, Dec 28, 1997 at 01:04:14PM +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:04:14PM +1100, Bruce Evans wrote: >> On the subject of remote debugging: the handbook entry is missing some >> other important information. I still haven't been able to get the >> link to work. After considerable digging in the sources, I found that > >> 3. At some point, on the debugged machine, I re-enter the debugger. >> It hangs after the message >> >> Debugger("manual escape to debugger") >> >> and (presumably) waits for communication from the debugging >> machine. >> >> 4. On the debugging machine, I enter >> >> target remote /dev/cuaa0 >> >> I get the messages: >> >> Remote debugging using /dev/cuaa0 >> Ignoring packet error, continuing... >> Ignoring packet error, continuing... >> Couldn't establish connection to remote target >> Malformed response to offset query, timeout > > Possibly a speed mismatch. 16550s may be required on the debugged machine. > It may work better to do step 3) before 4). As I mentioned in the original message, I tried both ways. >> So what gives? Do I have my serial config wrong? I've done >> everything according to the book, and there is no indication, neither >> in the documentation nor in the sources, about how to set up the bit >> rate, character size and such. I assume somebody has got this to >> work, but I can't work out how. > > Speed setting is fully doc^H^H^Hcoded in the sources. 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 end up in gdb_handle_exception, but it doesn't seem to set anything either. > It may work better to use a serial console or boot with -D. Interesting. I tried that, and it had *no* effect. If I understand it correctly, it should duplicate the boot messages onto a serial console. I had a cu waiting, but it saw nothing. I will investigate. > The speed will then be set by the boot blocks, and the kernel will > use the same speed (if it agrees with the boot blocks about the > port), and the h/w speed will be initialized (-current neglects to > initialize when the speed registers wouldn't change, but this may > leave the h/w behind the registers uninitialized after reset). 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 you're going to debug something over the line that it's using, but anything else is unclean. I'll take a look at it, but first I want to understand why it's not working now. Greg