freebsd stable - Apr 2016 - Toggling between remote KGDB and local DDB within a debugging session

Hello

I think the title says it all!! :)

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

I tried adding 'options KDB_UNATTENDED' but that does not make any
difference.

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:" Now when you type 'gdb' at
the
DDB prompt, KGDB takes over remotely. On continuing at the KGDB
prompt, you arrive back at the debugged machine but it is not longer
under the control of DDB.

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? When remote remote KGDB is listening and I force a
panic using 'sysctl debug.kdb.enter=1', it drops into remote KGDB.
However, when it is NOT listening on the serial port, the local 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? If yes please do let me know

-- 

Best Regards,
Aijaz Baig

On 19/04/2016 8:49 PM, Aijaz Baig wrote:
> Hello
>
> I think the title says it all!! :)
>
> 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??
you don't .. at teh moment I think it' s a one way street, but at one 
stage you could "detach"
and it wuld switch back to ddb.. I don't think that works any more..
I've looked at making it work more than once but never got enough of 
an understanding to make it work,
I suspect that it is a case of setting the appropriate word somewhere 
to teh appropriate value.
How to find that location from gdb is the hard part.


> My kernel configuration file already contains 'options
> BREAK_TO_DEBUGGER' and I have BOTH GDB and DDB configured aka:
> options GDB
> options DDB
>
> I tried adding 'options KDB_UNATTENDED' but that does not make any
difference.
>
> 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:" Now when you type 'gdb'
at the
> DDB prompt, KGDB takes over remotely. On continuing at the KGDB
> prompt, you arrive back at the debugged machine but it is not longer
> under the control of DDB.
>
> 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? When remote remote KGDB is listening and I force a
> panic using 'sysctl debug.kdb.enter=1', it drops into remote KGDB.
> However, when it is NOT listening on the serial port, the local 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? If yes please do let me know
>

On Tue, Apr 19, 2016 at 5:49 AM, Aijaz Baig <aijazbaig1 at gmail.com>
wrote:
> 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??
Ctrl-c on the serial console.
> When remote remote KGDB is listening and I force a
> panic using 'sysctl debug.kdb.enter=1', it drops into remote KGDB.
> However, when it is NOT listening on the serial port, the local system
> just freezes
Are you sure ddb just doesn't run on the serial port?
> 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.
Yes.  I regularly do this with ctrl-c (gdb->ddb) / "gdb"
(ddb->gdb).

Best,
Conrad

On Tue, Apr 19, 2016 at 9:08 PM, Conrad Meyer <cem at freebsd.org>
wrote:
> On Tue, Apr 19, 2016 at 5:49 AM, Aijaz Baig <aijazbaig1 at gmail.com>
wrote:
>> 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??
>
> Ctrl-c on the serial console.
For me I merely see 'Quit' being spat out when I do a
ctrl-c
>
>> When remote remote KGDB is listening and I force a
>> panic using 'sysctl debug.kdb.enter=1', it drops into remote
KGDB.
>> However, when it is NOT listening on the serial port, the local system
>> just freezes
>
> Are you sure ddb just doesn't run on the serial port?
For the very first time, a manual panic does indeed bring up the ddb
prompt. However it is only AFTER I've attached kgdb to it, does this
start happening, namely not going back ever to ddb (with 'Quit' being
displayed instead and with the control still with KGDB)
>
>> 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.
>
> Yes.  I regularly do this with ctrl-c (gdb->ddb) / "gdb"
(ddb->gdb).
If it'd help, I'm using VMs. So my serial console is actually the VM
console. Now just to be on the safe side I tried putting "comconsole"
into '/boot/loader.conf'. However now, with the aforementioned sysctl,
it doesn't drop to ddb even for the very first time unlike previous
trials where. dropping into DDB was smooth as long as KGDB was not
attached to it ever.
>
> Best,
> Conrad
Keen to hear from you

-- 

Best Regards,
Aijaz Baig