gdb over Firewire
Gerald Heinig
gheinig at syskonnect.de
Thu Feb 17 08:35:29 GMT 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.
[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.
More information about the freebsd-current
mailing list