Re: Some thoughts on Giant instrumentation

    First a 're-cap' of the various kernel-debugging resources that are
available and then a couple of suggestions from my own (somewhat limited)
experience蔊
   There are basically four different types of kernel debugging 'schemes'
that can be configured with what is commonly available in -Current:

  (1). Kernel debugging can be done (from user space) using the gdb
debugging (gdb -k kernelxxx) which can be used to do such simple things as
examine/set global variables,etc.

(2). A serial console can be set up (using a remote machine) using the ddb
debugger, and a kernel compiled on the host machine which had the 'Options
ddb' and associated 'break_to_debugger' options enabled in the kernel.
 
(3). The third is a option to remote (over serial line(s)) perform remote
kernel debugging using a 'stripped' kernel booted on a second machine and
running ddb/gdb from two serial consoles on the second (debugging) machine.

(4). The fourth option is to use a VMware virtual machine (running under
Current) and use it (as described on the list here at various times) to do
a versions of 'gdb debugging'. In my experience this arrangement is very
slow but does have the advantage of using only on pc for as a development
platform. 

     I think what needs to be added (and is sorely lacking) are some good
syscalls (that can be called from 'userland' to perform such things as dump
out the 'ktr' buffer from a user land program and show contents of some of
the other kernel parameters (when using a test program from user land). It
seems like a good set of 'debug syscalls' would be a good addition to the
smp code that is -current and would make debugging/development efforts
easier and more efficient for everyone :))

Glenn Gombert
[e-mail]


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-smp" in the body of the message