0
votes

I would like to know if there is indeed a way to toggle between gdb and ddb while debugging a remote kernel.

I am already at the gdb (or rather kgdb) prompt. From here how do I switch to local ddb on the debugged machine?

My kernel configuration file already contains options BREAK_TO_DEBUGGER and I have BOTH GDB and DDB configured aka:

options GDB
options DDB

As per the developer's handbook, "Every time you type gdb, the mode will be toggled between remote GDB and local DDB. In order to force a next trap immediately, simply type s (step). Your hosting GDB will now gain control over the target kernel:"

So, I did try typing 'gdb' at the gdb prompt (funny me:D) and as expected, it was an unrecognized command. Obviously, this command is supposed to be typed at the ddb prompt. But my question is, how do I drop to ddb from within a running machine whose serial ports (albeit virtual ones) are remotely attached to another machine's KGDB? When remote GDB is listening and I force a panic using sysctl debug.kdb.enter=1, it does drop into remote KGDB. However, when it is NOT listening, the system just freezes.

What I want, is to enter ddb on the local machine. Do some debugging using it; drop to remote KGDB for things that are best done using KGDB, then switch back to local DDB when I'm done.

Is there a way to do that?

1

1 Answers

0
votes

KDB contains DDB & KDB backends, but there are a lot of conditions when they are available. To check if backend is available, check sysctl debug.kdb.available and debug.kdb.current (sys/kern/subr_kdb.c). If both backends are available, debug.kdb.available should contains "ddb gdb".

The possible way to toggle between backends (gdb / ddb) is to enter ddb at first, then call gdb and make debugging. Then exit gdb, and return to ddb (actually new trap will happen, seems Ctrl+C is required). It means that before panic, debug.kdb.current should be set to "ddb".

I hope it will help.