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
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