conserver and gdb

We have some developers who are working on kernel code, and wish to do 
their kernel debugging using GDB (the Gnu DeBugger).  I am wondering 
whether anyone out there has made gdb work with conserver?

Background:  when debugging a UNIX kernel, the typical setup is to have 
two machines.  The "master" is the one on which GDB is run.  The 
"target" is the one on which the kernel-to-be-debugged is running.  The 
target must have a serial console, which is normlly connected to a 
serial port on the master.

GDB is then started on the master, and the command is given:

	(gdb) target remote /dev/ttyNN

where /dev/ttyNN is the serial device on the master to which the serial 
cable from the target has been attached.

With me so far?

Now, it turns out that GDB also allows the target to be a remote 
terminal, e.g. a port on a terminal concentrator, in which case the 
syntax of the command looks like this:

	(gdb) target remote cyclades-1.mydomain.com:5007

In this case, the target's serial console is attached to port 7 of a 
Cyclades box, and GDB is more-or-less running a Telnet session under the 
covers to connect the master and the target.

OK, here's the rub.  When using Conserver to manage all of the serial 
ports on my Cyclades box, all of the ports are "busy" because Conserver 
is connected to all of them.  But this prevents GDB from also attaching 
directly to the Cyclades port to establish a kernel debug session, using 
the second example above.

I could modify conserver.cf to not manage any port on which I want to do 
kernel debugging, but that's a pain, especially when the 
host-to-be-debugged is constantly changing.  It would be much nicer if 
gdb were Conserver-literate, and I could say something like

	(gdb) target conserver debug-host-7

But that would essentially require that GDB be modified to include 
pieces of the Conserver client code.

Has anyone tried to do this?  Or is there another way to handle this 
situation which (a) preserves Conserver access, and (b) doesn't involve 
a lot of manual manipulation on the part of the developer (or his admin)?

Thanks,
Steve L


-- 
--
steve lammert         test engineer   voice: +1-412-323-3500
slammert@panasas.com  panasas, inc.     fax: +1-412-323-3511