Re: gdb over Firewire

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.

[sorry about the off-topic post to -current]

Hi Greg,

thanks for the reply. I've actually got it to work now. I compiled dcons 
and dcons_crom into the kernel and upgraded to 5.3-STABLE on the 
debugging machine. In addition to this, there was something wrong with 
my target machine setup. I must have messed up the boot flags a while 
ago and forgotten about it, because the kernel kept waiting for remote 
gdb attach before it had probed the Firewire driver, which of course 
didn't work. Reinstalling a fresh 5.3-RELEASE on the target solved that 
problem.

The kgdb on 5.3-RELEASE doesn't support the IP forwarding functionality 
for remote devices; that's what the upgrade to -STABLE fixed.

So, 'standard' two-machine debugging works for me now.
However, what I'm _really_ interested in is the alternative 
non-cooperative Firewire debugging scheme you describe in your BSDCon paper.
Mine almost works, in that I can start up kgdb over /dev/fwmem0.0
However, there's no stack. What I get is:

# kgdb -c /dev/fwmem0.0 kernel.debug
[gdb copyright stuff]
0x00000000 in ?? ()
(kgdb)

Any ideas as to what I'm doing wrong?

Cheers,
Gerald

> 
> 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.
> 
> Greg
> --
> See complete headers for address and phone numbers.