Date: Tue, 20 Nov 2001 12:18:47 -500 From: <ahdaswan@unity.ncsu.edu> To: freebsd-hackers@freebsd.org Subject: Related to remote debugging using gdb Message-ID: <200111201718.MAA07992@uni02mr.unity.ncsu.edu> In-Reply-To: <Pine.GSO.4.33.0111201159290.22750-101000@uni01du.unity.ncsu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
Ive been trying to get to debug the kernel over a serial
connection, the environment: two virtual machines running
under VMware, connected via a serial port (/dev/pts/0) on
the host machine (linux),
I first boot the remote machine,
then the to debug machine with boot -d,
get to db> prompt, then db>gdb , then s, now Im hopefully
in the remote protocol that gdb supports.
on the remote machine I start gdb -k kernel
then gdb> target remote /dev/cuaa0
I keep getting
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
I looked around for an answer to this, and found Greg Leheys
post on the same issue, (his way to reach there looked different
though, but the problem seems to be the same) I couldnt find
an answer to his post (which is quite old, so surely someone
knows about this) Id appreciate any help.
(Gregs post included below)
thanks
Anil
-------------------------------------------------------------------------
FROM: Greg Lehey
DATE: 12/27/1997 20:24:01
SUBJECT: RE: Remote gdb (was: no boot: config -g and options DDB)
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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111201718.MAA07992>