Mailing List Archive

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

[. On Tuesday, February 26, 2002 at 13:34:10 (-0800), Bryan Stansell wrote: ]
> Subject: Re: conserver and gdb
>
> On Tue, Feb 26, 2002 at 03:44:46PM -0500, Steve Lammert wrote:
> >
> > 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...

Hmm..... I was on the verge of asking for something similar for the
nut-ups tools. I'd like to be able to gather stats from my conserver-
connected UPS'. That was what originally prompted me to ask about
reading and writing to a device through stdio of the "console" command.

I sure as heck can't "down" the UPS consoles every minute or so just to
collect the stats! ;-)

Even if I couldn't read the result back from a pipeline to "console" I
had contemplated just sending the command to the UPS that way and then
collecting the result from the log file. For nut-ups and/or Cricket I
could even separate the sending of the command and the collecting of the
data. A cron job to do "echo f | console -f ups.1", and with timestamps
in the log even Cricket can easily gather reliable stats with a not too
complicated EXEC script. However like GDB, 'nut-ups' ideally needs more
direct access to the UPS console for other purposes beyond stats
collection.

--
Greg A. Woods

+1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>

Bryan Stansell wrote:

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


Um. Yes. That would be a Bad Thing.

Of course, it would violate the Reasonable Person Principle for people
to grab the console away. Users should "spy" first (and, happily, this
is the default behavior when you connect to an in-use console) and only
force RW mode when appropriate, and be soundly drubbed otherwise.

But, down-ing the port would be an acceptable alternative, I think. Not
as convenient for developers (they have to remember port numbers, or
know how to look them up) and, for sure, they wouldn't remember to "up"
them afterwards, so logs would get stale... but it's worth writing up a
few paragraphs and getting some developers to give it a whirl.

Thanks for the clear thinking on my problem, and for your other comments
as well!


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