gdb over Firewire

[Tai-hwa Liang]

On Thu, 17 Feb 2005, Greg 'groggy' Lehey wrote:
> On Friday, 11 February 2005 at 10:11:31 +0100, Gerald Heinig wrote:
>> Hello Current'ers,
>>
>> I'm trying to get two-machine kernel debugging over Firewire working,
>> unfortunately without much luck so far. dconschat over Firewire works
>> fine, but gdb won't attach, complaining about get_tty_state failed,
>> among other things.
>> Is kernel gdb over Firewire a -current-only feature?
>
> Sorry for the slow reply; I've been busy.
>
> No, it's not a current-only feature.  It used to work, but I've had a
> lot of difficulty since the introduction of the new gdb framework.
>
> Try this:
>
>  $ sysctl debug.kdb
>  debug.kdb.available: ddb
>  debug.kdb.current: ddb
>  debug.kdb.enter: 0
>  debug.kdb.stop_cpus: 1
>
> That's what I get, and it indicates that I don't have gdb capability.
> If that's what you get, try building a kernel with firewire support
> built-in (as opposed to the (recommended) method of loading the
> firewire klds later).  The background here is the hypothesis that the
> kernel checks for debug back-ends at boot time, and not later, so if
> you load the firewire klds later, it won't be registered.
> Note that this is a hypothesis.  If you try this, please let us know
> what happens.

   From my observation, only "device dcons" is necessary to be static
linked in kernel, the rest such like firewire.ko and dcons_crom.ko
can still be dynamically loaded.