Date: Sun, 28 Dec 1997 12:11:57 +1030 From: Greg Lehey <grog@lemis.com> To: Chris Timmons <skynyrd@opus.cts.cwu.edu> Cc: Bruce Evans <bde@zeta.org.au>, freebsd-current@FreeBSD.ORG Subject: Remote gdb (was: no boot: config -g and options DDB) Message-ID: <19971228121157.21772@lemis.com> In-Reply-To: <Pine.BSF.3.96.971227163221.5475A-100000@opus.cts.cwu.edu>; from Chris Timmons on Sat, Dec 27, 1997 at 04:36:02PM -0800 References: <199712272314.KAA30548@godzilla.zeta.org.au> <Pine.BSF.3.96.971227163221.5475A-100000@opus.cts.cwu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 27, 1997 at 04:36:02PM -0800, Chris Timmons wrote:
> On Sun, 28 Dec 1997, Bruce Evans wrote:
>
>>> but it boots when I strip -x the kernel like it says to do in the
>>> handbook. "never mind" :)
>>
>> It shouldn't say that. -x breaks everything that needs static symbols,
>> e.g., systat. -d is correct.
>
> It says that in the section about remote debugging using gdb.
Correct. It's wrong, Bruce is right.
> Should I be able to boot a kernel that is config -g'd with options
> DDB and not stripped?
Yes, and it makes sense if you want to use ddb to debug your system.
But the debug kernel takes up about 10 MB of RAM, which is why I asked
my previous question: 16 MB is rather too small, though it shouldn't
cause a hang.
> I was thinking that I would want to config -g to make a more interesting
> dump when I call panic from in ddb, allowing me to do some poking later
> with KGDB.
Good thinking. That's why I do it this way as well.
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
the serial line on the debugged machine must be sio0, but even after
changing the hardware configuration accordingly, I can't get it to
work. Here's the situation:
1. First, establish that I can set up conventional communication with
getty and cu. No problems. I'm using a crossover cable.
2. On the debugging machine, I enter ddb and issue the gdb command as
described, and get the expected message
Next trap will enter GDB remote protocol mode
Then I continue execution.
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
And that's all. The debugged machine waits for ever, and I need to
press the Big Red Button to continue. Looking with a breakout box, I
see that the debugged machine isn't asserting any modem control
signals, but that doesn't seem to be the problem: the debugging
machine sends data anyway, and setting the breakout box to provide
RTS, DTR and CD doesn't help. I've also tried having the debugging
machine trying to establish contact when I re-enter ddb on the
debugged machine (in other words, do step 4 just before step 3).
Still no communication.
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.
Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971228121157.21772>