Re: conserver and gdb

hi steve,

On Tue, Feb 26, 2002 at 03:44:46PM -0500, Steve Lammert wrote:
> 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?

great question!  this should be good!

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

yikes...wouldn't want to inflict that upon anyone.  that's the one
chunk of code i've been afraid to touch too much (although it might be
next on my hit list).  but, anyway...

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

let me ask a question and see if your philosophy changes at all.  first
let me say that i haven't used gdb in it's remote mode to do any
debugging and haven't looked at what it expects.  but, considering it's
support is for a dedicated serial line or a tcp connection (which is
normally dedicated), i can only assume it wouldn't want to see traffic
that it wasn't expecting.  so, the question is, is this true?  how does
this matter if you're using conserver's client code, you may ask?
well...

if gdb did have the client code and someone else forcefully took over
the console, gdb would be bumped into spy mode and, i assume, get out
of sync with the debugged kernel.  you see, the fun part of the
client-server code is that there is no knowledge on the client side of
what's going on.  it basically sets up a connection (through a series
of interesting moves), logs in, and then blindly passes traffic back
and forth (which, in my mind, is a nice feature, but has it's
limitations).  knowing when you're in spy mode, when the console is
down, when others bump you - it's all done in the brain of the user.
so, even if gdb had the client code, it wouldn't be able to know what
state the console was in or how to recover without rewriting most of it
to watch for special strings in the traffic (which is problematic at
best).

so, my initial reaction is to suggest that you "down" the console by
connecting with the client and using the '^ecd' sequence.  before you
down it you could even type a nice little message for anyone else who
connects and replays the last few lines.  then, crank up gdb using the
remote tcp port functionality (i'd keep the console client connection
going just so you're the one in write mode and you see if someone else
is trying to mess with the port).  heck, you could also use '^ecx' to
find out what the terminal server and port numbers should be (so you
don't have to dig through the cf file).  then, when you're done
debugging the kernel, you disconnect gdb, use '^eco' to reconnect
conserver, and move on.

there's my initial thoughts on the whole thing.  one of the "wishlist"
items is to be able to redirect a command's i/o through the client.
basically, you'd start up the client, connect, use a new sequence like
'^ec|', give it a command, and it would fork the command off on the
client, allowing it to chat with the console (and blocking others from
bumping the command off).  unfortunately, it's tricky (for a lot of the
same reasons as above).  but, i'm still thinking about if and how it
could be done and that *might* be a future solution.  but, that too has
it's issues for gdb since stdin/stdout should still be the user
interaction with gdb and some other pipe should be the interaction with
gdb (i was thinking of just redirecting stdin/stdout of the command to
the console).

anyway, i hope something here helps and gives you a little insight into
the inner-workings of the code.  maybe with the info above you or
someone can come up with a better solution than what i've suggested (or
ideas for code changes).

Bryan