Date: Sun, 28 Dec 1997 12:54:01 +1030 From: Greg Lehey <grog@lemis.com> To: Bruce Evans <bde@zeta.org.au> Cc: skynyrd@opus.cts.cwu.edu, freebsd-current@FreeBSD.ORG Subject: Re: Remote gdb (was: no boot: config -g and options DDB) Message-ID: <19971228125401.34698@lemis.com> In-Reply-To: <199712280204.NAA01965@godzilla.zeta.org.au>; from Bruce Evans on Sun, Dec 28, 1997 at 01:04:14PM %2B1100 References: <199712280204.NAA01965@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971228125401.34698>