Re: GDB Stub & GPL question

Re: GDB Stub & GPL question

[veenu khanna]

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

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

Do you have any leads/ideas about how have people handled this problem ? Is it do-able ? or the only way to debug multiple processes is to have multiple instances of gdbserver. 


Thanx in advance 


----- Original Message ----
From: Daniel Jacobowitz <drow@false.org>
To: veenu khanna <veenu_khanna@yahoo.com>
Cc: gdb@sourceware.org
Sent: Wednesday, January 31, 2007 4:04:48 PM
Subject: Re: GDB Stub & GPL question

On Wed, Jan 31, 2007 at 07:02:04AM -0800, veenu khanna wrote:
> Hello
> I have a question regarding implementing a remote stub. Say we have to implement/extend a stub for x86 architecture with our own OS.
> IN section for "Implementing a remote stub (Section 17.5.3)" in "Debugging with GDB" document there is a point
> "Make sure you have a serial connection between your target machine and the gdb host,
> and identify the serial port on the host."
> 
> Does this mean that GDB on host and GDB agent/stub on the target can only talk on a serial port ? 
> 
> And in point 7 it says "Start gdb on the host, and connect to the target" in which TCP connection is allowed as well.
> 
> Can someone help me in getting things right ? 
> I know that it is possible to have a TCP communication between gdb and gdbserver. 
> Is there a support for the same for stubs ? 

Yes, it's exactly the same - I'm sorry the manual is unclear.

> Another question is regarding GPL...
> some part of stub code will be residing in our kernel which is proprietary. 
> Does that mean we will have to release the code for kernel as well ? 

If you copy the stub from the GDB source tree, then yes you would
have a GPL problem.  I recommend writing one from scratch, instead,
based on the documentation - that's what most people seem to do.
The examples in GDB are quite old.

-- 
Daniel Jacobowitz
CodeSourcery





 
____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail

Re: GDB Stub & GPL question

[Daniel Jacobowitz]

On Fri, Feb 09, 2007 at 07:21:22AM -0800, veenu khanna wrote:
> You mean to say that if we implement our own stub for gdb then it HAS
> to be a serial connection. It can not be IP based.

No, TCP should work fine.

> We are pondering over the idea to implement a gdb & gdbserver/stub
> solution for our proprietary OS (embedded arch) And I have few doubts
> about the viability. It seems that multiple instances of gdbserver
> needs to be launched to connect it to multiple processes. Is there a
> way to debug multiple processes with single gdbserver instance ?  Say
> we write our own command in gdb to list all the processes in our OS.
> And then we do an attach from gdb like attach <pid> .
> 
> Do you have any leads/ideas about how have people handled this
> problem ? Is it do-able ? or the only way to debug multiple processes
> is to have multiple instances of gdbserver.

A single GDB can only control one process at a time.  By process I mean
a program running with a shared data space; multiple threads of the
same process are fine.

So if you want to debug multiple different processes, then you need to
be able to connect one GDB to your target for each process you want to
debug.  That can be one stub handling multiple connections, or many
instances of the stub.

I once wrote some extensions to the remote protocol to allow you to
connect to a stub and use the "attach" command to attach to a process
on the remote system.  I haven't merged them to GDB HEAD yet, but I
hope I'll get a chance to do that this year.


-- 
Daniel Jacobowitz
CodeSourcery

Breakpoint Handling For Dynamic Processes

[veenu khanna]

Hello,
Thanx for you replies. I have another question.

In our OS, one can only attach to a process when it is running.
And we only have dynamic processes.
Hence, arises the problem of applying a breakpont to stop a
process.
Thus, We need a way to apply a breakpoint even before a process
is attached. 
What if we write a special stub which has the responsibility to
apply breakpoints on the target. These bps will end up in some
process address space. 
So When a process will be attached to via another stub say
(gdbserver), Will gdb be aware of all the bps for this process
which were applied even before an attach took place?
And will it behave in the usual way like when a BP would have
been applied after a process was attached.

Or does anyone have ideas on how to solve the problem of
debugging dynamic processes which can only be attached to if it
is running.

Veenu 


 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

Re: GDB Stub & GPL question

[Paul Koning]

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