Date: Wed, 01 Nov 2006 10:10:10 -0800 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: remote gdb, kgdb and ddb Message-ID: <4548E302.7040008@elischer.org> In-Reply-To: <200611011143.08632.jhb@freebsd.org> References: <4547F4C9.5020902@elischer.org> <200611011143.08632.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Tuesday 31 October 2006 20:13, Julian Elischer wrote: >> it's been a bew years since I did this.. >> >> some questions.. >> >> why kgdb instead of gdb -k ? >> >> for remote, gdb seems to work fine >> kgdb -r /dev/cuad0 kernel.debug thinks it's working but seems to get >> confused a lot.. > > No idea, ask marcel perhaps. I only use kgdb on coredumps. > >> gdb with the following .gdbinit file seems to work as well. >> file kernel.debug >> set verbose 1 >> set remotebreak 1 >> set remotebaud 9600 >> set remotedevice /dev/cuad0 >> target remote /dev/cuad0 >> >> though I'm not convinced I'm seeing the last frame in which the >> trap occurs. (ddb shows one more frame). > > This is one of the things kgdb fixes (it has frame sniffers for trapframes). > >> Now that I have my machine in remote gdb, the documentation >> (as sparse as it is) doesnt't say how to make the machine reboot. >> >> from ddb I can do 'call cpu_reset' which seems to work, but >> I haven't succedded in making gdb do anything similar, >> nor to drop back into ddb. At one stage 'detach' used to do that >> but it seems to have stopped working. > > Try the following from src/tools/debugscripts/gdbinit.kernel: > > # Switch back to ddb > define ddb > set boothowto=0x80000000 > s > end > document ddb > Switch back to ddb. > end > cool I'll try it today. > I think I used to use that a few years ago. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4548E302.7040008>