Date: Fri, 02 Jan 2009 00:46:09 -0800 From: Bakul Shah <bakul@bitblocks.com> To: "Pranav Peshwe" <pranavpeshwe@gmail.com> Cc: freebsd-hackers@freebsd.org, shilp.kamal@yahoo.com, freebsd-questions@freebsd.org Subject: Re: FreeBSD kernel Debugging tools for Virtual Memory Module Message-ID: <20090102084609.8F5A35B05@mail.bitblocks.com> In-Reply-To: Your message of "Fri, 02 Jan 2009 12:40:08 %2B0530." <cdfd7d6d0901012310k7299a564ifeb41af432bebc9d@mail.gmail.com> References: <387210.21917.qm@web45407.mail.sp1.yahoo.com> <cdfd7d6d0901012310k7299a564ifeb41af432bebc9d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> ddb and kgdb are two useful and often indispensable tools for kernel > debugging on FBSD. ddb won't allow you source level debugging, kgdb will, > but you'll need an extra machine. If the code you are debugging doesn't depend on specific hardware, one option is to run FreeBSD (with the kernel being debugged) under qemu and run kgdb on the host FreeBSD. Something like In Window1 $ qemu -s freebsd-disk-img ... In Window2 $ cd <where the kernel under test was built> $ kgdb kernel.debug (gdb) target remote localhost:1234 <do your debugging> (gdb) detach Ending remote debugging. (gdb) q $ Note: I have not tried this recently but it should work. > AFAIK, if you are modifying the kernel source directly there is no option > but to recompile all the changed and dependent files. Well... there used to be a debugger called ups with a builtin C interpreter. It allowed you to add code at run time. This was quite handy when you wanted to temporarily patch things up and continue debugging or set conditional breakpoints or insert assertion verification code on the fly. The C interpreter is worth adding to gdb but I am not sure if any of ups code can be reused. See http://ups.sourceforge.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090102084609.8F5A35B05>