Date: Tue, 13 Apr 2004 00:34:44 -0700 (PDT) From: Marcel Moolenaar <marcel@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 50979 for review Message-ID: <200404130734.i3D7YieI002599@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=50979 Change 50979 by marcel@marcel_nfs on 2004/04/13 00:34:24 Initial commit of a new tool: kgdb(1). The files are skeletal, so there isn't anything interesting to say about their contents. However, this is the perfect time to explain why there's going to a be kgdb(1): The kgdb(1) tool is an experiment (with the intention to be committed if the experiment succeeds -- for an unspecified definition of succeed). The primary intend is to avoid having to add our local tweaks and hooks into gdb(1) for the sole purpose of being able to debug kernels. These tweaks and hooks include such things as a the -k option, the kcore pseudo target that interfaces with libkvm and our KLD hooks. So how is it supposed to work then? kgdb(1) is a shell on top of gdb(1) that establishes a remote debugging session in the same way that we can debug kernels remotely. This way, any kernel specific details will be present in the gdb stub, which lives in kgdb(1). This includes the interfacing with libkvm, loading KLDs and registering those with gdb. This setup has some nice properties and allows for some nice features: o There's only one way in gdb(1) to debug kernels: through a remote target. This means that there's less code and less variation to worry about. From a maintenance PoV a winner. o The debugger does not need to know anything about the kernel or its core file. Upgrading gdb(1) is easier and we don't have a hard time changing aspects of the kernel that break debugging, because we have everything in our own tree under our own control. Hence, we can more easily change core file formats mid-flight or support whatever non-standard formats we may need. o With kgdb(1) a shell, we can add our own set of commands to interpret kernel data or add all kinds of conveniences into the tool to make debugging the kernel easy. o Since we know what we're debugging, we can more easily find the right kernel object files that match the core file. This may become automagical even... The intend is to have kgdb(1) spawn gdb(1), set up the various pipes between the two processes, pass some commands to gdb(1) to set things up and then present the prompt. From there it should behave no different than gdb(1). Affected files ... .. //depot/projects/gdb/usr.bin/kgdb/Makefile#1 add .. //depot/projects/gdb/usr.bin/kgdb/kgdb.1#1 add .. //depot/projects/gdb/usr.bin/kgdb/main.c#1 add Differences ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404130734.i3D7YieI002599>