GDB Stub & GPL question

GDB Stub & GPL question

[veenu khanna]

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 ? 

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 ? 

Thanx
Veenu





 
____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

Re: GDB Stub & GPL question

[Daniel Jacobowitz]

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

Re: GDB Stub & GPL question

[Nicholas Mc Guire]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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 ?
>>
>> 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.
>
thats stange - considering the boilerplate on gdb-6.6/gdb/*-stub.c
clearly stating:


                 THIS SOFTWARE IS NOT COPYRIGHTED


how does that fit with there being a GPL problem ? - if there really is
then these headers sould be changed as the expectation is clearly 
different.

hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFFwN0rnU7rXZKfY2oRAnzRAJ401TITCfM+qMaNkuYi/QKnOo174gCfWeIM
GgGViqckwv7Fy99KGVCvaQY=
=8U8j
-----END PGP SIGNATURE-----

Re: GDB Stub & GPL question

[Daniel Jacobowitz]

On Wed, Jan 31, 2007 at 07:17:13PM +0100, Nicholas Mc Guire wrote:
> thats stange - considering the boilerplate on gdb-6.6/gdb/*-stub.c
> clearly stating:
> 
> 
>                 THIS SOFTWARE IS NOT COPYRIGHTED
> 
> 
> how does that fit with there being a GPL problem ? - if there really is
> then these headers sould be changed as the expectation is clearly 
> different.

Then I was mistaken; sorry.

Answers on this list obviously do not qualify as legal advice; if you
have a concern, ask the FSF or your own lawyers.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB Stub & GPL question

[Robert Dewar]

Nicholas Mc Guire wrote:

>                  THIS SOFTWARE IS NOT COPYRIGHTED
> 
> how does that fit with there being a GPL problem ? - if there really is
> then these headers sould be changed as the expectation is clearly 
> different.

Such a header has no legal significance, so if you want to copy
this code, it is up to you to check that the author has indeed
issued an appropriate license, and/or disclaimed copyright (I
think this is possible in the US, it is not possible in many
European countries as I understand things).

Also, any answer you get to a legal question about licensing
on this forum has no legal significance (and that includes
this answer).

Re: GDB Stub & GPL question

[Nicholas Mc Guire]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Nicholas Mc Guire wrote:
>
>>                  THIS SOFTWARE IS NOT COPYRIGHTED
>> 
>> how does that fit with there being a GPL problem ? - if there really is
>> then these headers sould be changed as the expectation is clearly 
>> different.
>
> Such a header has no legal significance, so if you want to copy
> this code, it is up to you to check that the author has indeed
> issued an appropriate license, and/or disclaimed copyright (I
> think this is possible in the US, it is not possible in many
> European countries as I understand things).
>
> Also, any answer you get to a legal question about licensing
> on this forum has no legal significance (and that includes
> this answer).
>
well I did not post an answer I posted a qutestion of "how does
that fit with a GPL problem" - that this list does not need an explicid
INAL in every mail is clear to everybody I hope ;)

Never the less it would make sense to change these boilerplates if they
do not provide any legally relevant information as they do lead to 
confusion when read by some people (me atleast).

hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFFwW27nU7rXZKfY2oRAiqPAJ0enk3P0Qh7HHlzeYBMPvRKVNnM5QCfT519
5MdTIYlsayj2ecLdjkyOZO8=
=Fz7X
-----END PGP SIGNATURE-----

Re: GDB Stub & GPL question

[Robert Dewar]

Nicholas Mc Guire wrote:

> Never the less it would make sense to change these boilerplates if they
> do not provide any legally relevant information as they do lead to 
> confusion when read by some people (me atleast).

Absolutely, it is appropriate that headers be right. Even if copyright
notices are no longer a legal requirement, they should be present and
correct (and the copyright office thinks they may be relevant in an
"innocent infringement" defense which might mitigate damages, see

http://www.copyright.gov/circs/circ03.html

Re: GDB Stub & GPL question

[Mark Kettenis]

> Date: Wed, 31 Jan 2007 10:04:48 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> > 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.

I actually recommend releasing all your code under the GPL.

(sorry couldn't resist)

Mark

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

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