Kernel debugging - Couldn't establish connection to remote target

Hi All,

Trying to get a remote debugger up and running as per On-Line Kernel Debugging Using Remote GDB

This is where I am at:
Both systems are: FreeBSD 8.2-RELEASE-p4

The target Setup:
KERNCONF:
Code:
makeoptions	DEBUG=-g
options		KDB
options		KDB_TRACE
options		DDB
options		GDB
boot/device.hints:
Code:
hint.uart.0.flags="0x00080"
Code:
# cd /usr/src
# make buildkernel MYKERNEL
# make installkernel MYKERNEL
# cd /boot/kernel
# strip -x *
# shutdown -r now
Target Debugging:
Code:
OK boot -d
Code:
GDB: debug ports: uart
GDB: current port: uart
KDB: debugger backends: ddb gdb
KDB: current backend: ddb
KDB: enter: Boot flags requested debugger
[thread pid 0 tid 0 ]
Stopped at	kdb_enter+0x3a: movl	$0,kdb_why
db>
At this time I start the host debugger, then:
Code:
db> gdb
Step to enter the remote GDB backend.
db> s
At this point it appears to be dead locked, Get no KB response, so Power OFF after waiting awhile!

The host Setup:
Code:
# cd /usr/obj
# mount /remote/usr
# cp -Rp /remote/usr/obj/usr .
# umount /remote/usr
Host Debugging:
Code:
# cd /usr/obj/usr/src/sys/MYKERNEL
# kgdb kernel
 Copyright ... ETC ...
 .
 .
 .
 This GDB was configured as "i386-marcel-freebsd"...
 (kgdb) target remote /dev/cuau0
 Remote debugging using /dev/cuau0
 Ignoring packet error, continuing...
 .
 .
 .
 Couldn't establish connection to remote target
 Malformed response to offset query, timeout
 (kgdb)

I have tested the NULL modem cable, it is correct w/Full handshake, I have also tried others.

Any ideas/suggestions/help would be greatly appreciated.

Thanks

-Enjoy
fh : )_~
 
FestusHagen said:
Code:
# cd /usr/src
# make buildkernel MYKERNEL
# make installkernel MYKERNEL
# cd /boot/kernel
# strip -x *
# shutdown -r now

I'm guessing you're still running the GENERIC kernel as these commands are not correct.

Code:
# make buildkernel [b]KERNCONF=[/b]MYKERNEL
# make installkernel [b]KERNCONF=[/b]MYKERNEL
 
SirDice said:
I'm guessing you're still running the GENERIC kernel as these commands are not correct.

Code:
# make buildkernel [b]KERNCONF=[/b]MYKERNEL
# make installkernel [b]KERNCONF=[/b]MYKERNEL

Thank you for looking and pointing that out, My apologies though, I did in fact incorrectly type that up in relation to this post. I wish it was that simple ...

Though in my case (and it should have been done BTB) the only error was in adding the 'e' to the end of make, I use a script called 'mak' to run make, it does all the dirty work like validating the symlinks to the kernconf and any modified sources, etc ... all inside script(1) so it's logged.

Target:
[CMD=]uname -v[/cmd]
Code:
FreeBSD 8.2-RELEASE-p4 #0: Wed Nov 16 19:34:42 EST 2011     
[email]fh@bynaus.XXXX.com[/email]:/usr/obj/usr/src/sys/GENDBG

Host:
[CMD=]uname -v[/cmd]
Code:
FreeBSD 8.2-RELEASE-p4 #0: Wed Nov 16 20:16:20 EST 2011     
[email]fh@zathras.XXXX.com[/email]:/usr/obj/usr/src/sys/GENHPDC76

It appears to be gdb(1) on the target, total system freeze upon trying to connect to remote.

-Enjoy
fh : )_~
 
Hi all,

After adding:
Code:
console="comconsole"
to /boot/loader.conf

The systems boots to:
Code:
Loading /boot/defaults/loader.conf
-

At this point if one uses tip(1) on the host to establish a connection with the target, one can then escape to the loader prompt and type:
Code:
boot -d
and it proceeds to the ddb(4) prompt, then it's possible to start kgdb(1) on the host and continue.

It is beneficial to have a long "autoboot_delay".

Unfortunately I have yet to find a way out of tip(1) other the kill(1)'ing it.

-Enjoy
fh : )_~
 
FestusHagen said:
Unfortunately I have yet to find a way out of tip(1) other the kill(1)'ing it.
From the tip(1) man page:
Typed characters are normally transmitted directly to the remote machine (which does the echoing as well). A tilde (`~') appearing as the first character of a line is an escape signal; the following are recognized:

~^D or ~.
Drop the connection and exit. Only the connection is dropped - the login session is not terminated.
 
Thanks SirDice.

Like I said, I have yet to find a way out of tip(1) other then kill(1)'ing it. That is during this process, normal use of tip(1) exits fine.

[SmartAlec]
Wonder how I figured out how to use tip(1) to do this without the use of man pages!

By learning how to read man pages ~20 years ago when I first started running FreeBSD, Yup that was before it was called FreeBSD! (Thanks Jordan)
[/SmartAlec]

-Enjoy
fh : )_~
 
In MYKERNEL:
Code:
makeoptions	DEBUG=-g
options		KDB
options		KDB_TRACE
options		DDB
options		GDB

/boot/device.hints:

Code:
hint.uart.0.flags="0x00080"

Code:
# make buildkernel KERNCONF=MYKERNEL
# make installkernel KERNCONF=MYKERNEL
# cd /boot/kernel
and then reboot

What should I do to successfuly debug the kernel on vmware workstation???
 
Back
Top