Re: GDB Stub & GPL question

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "veenu" == veenu khanna <veenu_khanna@yahoo.com> writes:

 veenu> HI Daniel, I am still unclear. :( You mean to say that if we
 veenu> implement our own stub for gdb then it HAS to be a serial
 veenu> connection. It can not be IP based.

I don't think that's what Daniel said.  

One of the forms of the "set target remote" command takes an IP
address and port number as argument.  If you use that form, GDB will
speak Telnet to that address.

One way to use this is to have a target whose stub talks to a serial
port, and plug a Telnet terminal server into that port.  This is a
handy scenario for embedded devices where a serial port is readily
available. 

Another way is to have a target that speaks TCP/IP itself, and accepts
data in Telnet form on that port.  Gdbserver is an example.  You could
also write your own stub to work that way.

>From the point of view of GDB, these two cases are the same.

 veenu> I have another question as well.  We are pondering over the
 veenu> idea to implement a gdb & gdbserver/stub solution for our
 veenu> proprietary OS (embedded arch) And I have few doubts about the
 veenu> viability.  It seems that multiple instances of gdbserver
 veenu> needs to be launched to connect it to multiple processes. Is
 veenu> there a way to debug multiple processes with single gdbserver
 veenu> instance ?  Say we write our own command in gdb to list all
 veenu> the processes in our OS. And then we do an attach from gdb
 veenu> like attach <pid> .

I've tried such a thing in a kernel debug environment (where I can
tell the debugger to attach to any of the user processes).  It can be
made to work to some extent.  

GDB works on a single executable image with a single set of shared
libraries.  It took a lot of hammering to be able to switch from one
executable to another, and one set of libraries to another (or the
same library at a different base address, which amounts to the same
issue).  I got it to work somewhat, but not very well.  Fortunately it
wasn't a critical need.

Gdbserver is very small, and of course much of it is shareable.  The
simple answer is to run multiple instances, and connect one instance
of GDB to each Gdbserver.  That works perfectly.  The overhead is
trivial.  Why make it harder than it needs to be?

	  paul