Where is GDB going

Where is GDB going

[Andrew Cagney]

Just FYI,

I'm currently aware of three significant and ongoing architectural
developments in GDB (I use the word `ongoing' loosely as like any work
it suffer from fits and starts):

	o	mi/libgdb/cli

		An interface for building better
		and more robust GUIs.  If is signficant
		as it involves separating the CLI
		from the core of GDB.

	o	multi-arch

		Allowing GDB to debug more complex
		targets containing several architectures

	o	async/event-loop

		Eliminating the assumption that
		the world stops when the target

Beyond that I also know of some more localized development (C++
cleanup/revamp, harvard/segment architecture discussion, ...).

	Andrew

Re: Where is GDB going

[Quality Quorum]

On Fri, 23 Feb 2001, Andrew Cagney wrote:

> Just FYI,
> 
> I'm currently aware of three significant and ongoing architectural
> developments in GDB (I use the word `ongoing' loosely as like any work
> it suffer from fits and starts):
> 
> 	o	mi/libgdb/cli
> 
> 		An interface for building better
> 		and more robust GUIs.  If is signficant
> 		as it involves separating the CLI
> 		from the core of GDB.
> 
> 	o	multi-arch
> 
> 		Allowing GDB to debug more complex
> 		targets containing several architectures
> 
> 	o	async/event-loop
> 
> 		Eliminating the assumption that
> 		the world stops when the target
> 
> Beyond that I also know of some more localized development (C++
> cleanup/revamp, harvard/segment architecture discussion, ...).

I am playing with (1) the idea of rewriting it in C++, the thing got grown
complex enough to justify these efforts (I suppose it may provide a
good pay off into multi-arch) and (2) with the idea of separating native
and cross-debugging in the process, while preserving the common interface
and structure.

However, I had a short but unpleasant private discussion with RMS about
GPL 3.0 from which I concluded (1) that it may preclude proprietary
software debugging with future versions of GDB by closing protocol linking
loophole in GPL 2.0, (2) that it will be for sure impossible (and it is 
may be illegal right now) to link gdb with proprietary software driving
various hardware probes. So, I am staying quite discuraged from working in
this area at all. 

> 
> 	Andrew
> 

Thanks,

Aleksey

Re: Where is GDB going

[Steven Johnson]

Quality Quorum wrote:
> 
> 
> However, I had a short but unpleasant private discussion with RMS about
> GPL 3.0 from which I concluded (1) that it may preclude proprietary
> software debugging with future versions of GDB by closing protocol linking
> loophole in GPL 2.0, 

Im guessing that you mean linking to a GPL Program, that is necessary
for  your program to work, using a communication protocol (say, on top
of TCP/IP) instead of binary linking (say, using a loadable/linked
library) would imply that the connecting program needs to be GPL?

This does not make sense, and given the history of the FSF and the GPL
where they created free alternatives to commonly available Unix
Utilities (some of which could inter-communicate using comms protocols)
is also paradoxical.  If this was the case then if Samba used GPL3.0
then you would not be able to share files with MS Windows unless MS
Windows was GPL!!  Bye Bye Samba :(  I Must have misunderstood what you
mean here, could you explain what this loophole is?  

> (2) that it will be for sure impossible (and it is
> may be illegal right now) to link gdb with proprietary software driving
> various hardware probes. 
I Agree with this.  There are way too many vendors making Windows DLL's
for their proprietary debug Hardware, and cluttering GDB with Hooks to
those DLL's.  This is (in my opinion) a clear brach of the GPL (in
spirit if not in word).  These vendors are riding off the back of the
work done by and for the FSF without contributing anything back.  And in
some cases these vendors are obstructionist in even allowing people to
write properly GPL'd alternatives to their Closed Windows DLL.  I don't
think it should be allowed, or supported by the GDB community and Any
patches to GDB that do this trick should be rejected out of hand. See
ser-ocd.c and v850ice.c (in alphabetical order) for examples of this in
the current GDB source.  These vendors should either open up their
direct interfaces to their debuggers or they should not expect a free
debugger in GDB.  This is a classic "Free as in Beer" not "Free as in
Freedom" situation.  There are also other Vendor specific versions of
GDB with similar closed interfaces.

This is wrong, and should not be tolerated or encouraged.

> So, I am staying quite discuraged from working in
> this area at all.
> 

I would be very discouraged as well, if your first point is as i've
interpreted it.  But this can not be so as it is non-sensical.  The
second point shouldn't discourage you, it should enourage you that maybe
these abuses are going to be prevented.  At the end of the day, there
are no readilly available processors that have GPL microcode or
execution units, so A Line has to be drawn, I think point 2 is valid,
but no one could convince me of the rationality of point 1.  (Or in fact
that you could only run GPL code on processors with GPL microcode.)

> 
> Thanks,
> 
> Aleksey

Regards,
Steven Johnson

Re: Where is GDB going

[Quality Quorum]

On Mon, 26 Feb 2001, Steven Johnson wrote:

> Quality Quorum wrote:
> > 
> > 
> > However, I had a short but unpleasant private discussion with RMS about
> > GPL 3.0 from which I concluded (1) that it may preclude proprietary
> > software debugging with future versions of GDB by closing protocol linking
> > loophole in GPL 2.0, 
> 
> Im guessing that you mean linking to a GPL Program, that is necessary
> for  your program to work, using a communication protocol (say, on top
> of TCP/IP) instead of binary linking (say, using a loadable/linked
> library) would imply that the connecting program needs to be GPL?
> 
> This does not make sense, and given the history of the FSF and the GPL
> where they created free alternatives to commonly available Unix
> Utilities (some of which could inter-communicate using comms protocols)
> is also paradoxical.  If this was the case then if Samba used GPL3.0
> then you would not be able to share files with MS Windows unless MS
> Windows was GPL!!  Bye Bye Samba :(  I Must have misunderstood what you
> mean here, could you explain what this loophole is?  

I hope I misunderstood RMS, however, I had asked him the same question
in a few variants, and response was about the same. I must note that 
(1) English is not my native language though and (2)I am not a lawyer.
 
> > (2) that it will be for sure impossible (and it is
> > may be illegal right now) to link gdb with proprietary software driving
> > various hardware probes. 
> I Agree with this.  There are way too many vendors making Windows DLL's
> for their proprietary debug Hardware, and cluttering GDB with Hooks to
> those DLL's.  This is (in my opinion) a clear brach of the GPL (in
> spirit if not in word).  These vendors are riding off the back of the
> work done by and for the FSF without contributing anything back.  And in
> some cases these vendors are obstructionist in even allowing people to
> write properly GPL'd alternatives to their Closed Windows DLL.  I don't
> think it should be allowed, or supported by the GDB community and Any
> patches to GDB that do this trick should be rejected out of hand. See
> ser-ocd.c and v850ice.c (in alphabetical order) for examples of this in
> the current GDB source.  These vendors should either open up their
> direct interfaces to their debuggers or they should not expect a free
> debugger in GDB.  This is a classic "Free as in Beer" not "Free as in
> Freedom" situation.  There are also other Vendor specific versions of
> GDB with similar closed interfaces.
> 
> This is wrong, and should not be tolerated or encouraged.

I agree that there should be a line in the sand, however, currently 
it is way far to the left. If people have intellectual property and 
trade secrets hardwired into their hardware, then they should be allowed
to protect these secrets from disclosure by writing closed library 
obscuring details of their stuff. Otherwise, I would not be 
surprised that say GPL 4.0 code would require verilog code of all chips 
it is driving to be GPLed too.

> > So, I am staying quite discuraged from working in
> > this area at all.
> > 
> 
> I would be very discouraged as well, if your first point is as i've
> interpreted it.  But this can not be so as it is non-sensical.

I can only hope.

> Regards,
> Steven Johnson

Thanks,

Aleksey

Re: Where is GDB going

[Per Bothner]

Quality Quorum <qqi@world.std.com> writes:

> I agree that there should be a line in the sand, however, currently 
> it is way far to the left. If people have intellectual property and 
> trade secrets hardwired into their hardware, then they should be allowed
> to protect these secrets from disclosure by writing closed library 
> obscuring details of their stuff.

Of course they should be.  RMS would agree 100%.  But you're missing
the point: if people make that choice, they have no right to expect a
free ride from Free Software.  What does Free Software (or the World
for that matter) gain by making it too easy for people to keep their
intellectual property secret?  The whole point of GNU to encourage
openness, not trade secrets.

Anyway, discussion about the morality of the GPL are not appropriate
to this mailing list.  Concrete questions about the licensing
implications of using Gdb remote stubs, probably ok, I guess.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Where is GDB going

[Quality Quorum]

On 25 Feb 2001, Per Bothner wrote:

> Quality Quorum <qqi@world.std.com> writes:
> 
> > I agree that there should be a line in the sand, however, currently 
> > it is way far to the left. If people have intellectual property and 
> > trade secrets hardwired into their hardware, then they should be allowed
> > to protect these secrets from disclosure by writing closed library 
> > obscuring details of their stuff.
> 
> Of course they should be.  RMS would agree 100%.  But you're missing
> the point: if people make that choice, they have no right to expect a
> free ride from Free Software.  What does Free Software (or the World
> for that matter) gain by making it too easy for people to keep their
> intellectual property secret?  The whole point of GNU to encourage
> openness, not trade secrets.

I do not think that I am missing the point. So, far GNU stuff was 
an enabling technology allowing a bunch of a small guys to pool
resources and provide ourselves with tools and systems where big 
dogs for years did not provide anything suitable and always overpriced.
However, most of the people who use GNU tools in embedded space 
are doing it to earn living off their PROPRIETARY applications being
developed/debugged with GNU tools. If GNU is going to become a
social engineering tool (as you just confirmed) it is going to die - 
this is just an opinion of information age's joe-six-pack, I am
interested in any more discussions on this topic.


> Anyway, discussion about the morality of the GPL are not appropriate
> to this mailing list.  Concrete questions about the licensing
> implications of using Gdb remote stubs, probably ok, I guess.

It was you idea to discuss this matter under this angle. I had 
a very simple question I would like to be either firmly confirmed or 
firmly denied. If I have i386-stub.c (which is public domain) linked with
my evil-proprietary-system then it will be breach of GPL 3.0 to debug
my evil-proprietary-system with GDB using GDB remote protocol.

So, far it was confirmed, while not that firmly.


> 	--Per Bothner

Thanks,

Aleksey

correction. Re: Where is GDB going

[Quality Quorum]

On Mon, 26 Feb 2001, Quality Quorum wrote:
> ... 
> I am interested in any more discussions on this topic.

It should be read:

I am not interested in any more discussions ...
 

Thanks,

Aleksey
 

Re: Where is GDB going

[Per Bothner]

Quality Quorum <qqi@world.std.com> writes:

> If GNU is going to become a social engineering tool ..

It has been, since it was launched in 1984.  Check www.gnu.org.

> It was you idea to discuss this matter under this angle.

No, you were whining that the GPL 3.0 might be preventing you
from using Gdb, and complaining this would be wrong.

> I had 
> a very simple question I would like to be either firmly confirmed or 
> firmly denied. If I have i386-stub.c (which is public domain) linked with
> my evil-proprietary-system then it will be breach of GPL 3.0 to debug
> my evil-proprietary-system with GDB using GDB remote protocol.

This cannot be confirmed, since GPL 3.0 does not exist.

I would not worry about GPL 3.0.  It is a hypothetical problem.  Your
concern should be whether GPL 2.0 allows you to do what you need to
do; I believe it does.  If a future GPL 3.0 is too restrictive, you
always have the option of sticking with an older version of Gdb.
The GPL does allow you to create your own fork, if you want to,
from say Gdb 5.0.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Where is GDB going

[Quality Quorum]

> 
> I would not worry about GPL 3.0.  It is a hypothetical problem.  Your
> concern should be whether GPL 2.0 allows you to do what you need to
> do; I believe it does.  If a future GPL 3.0 is too restrictive, you
> always have the option of sticking with an older version of Gdb.
> The GPL does allow you to create your own fork, if you want to,
> from say Gdb 5.0.

This was my point, there is no sense for me do anything new in this are
until these issues are firmly resolved one way or the other. Thank you for
reiterating.

> 	--Per Bothner

Thanks,

Aleksey

Re: Where is GDB going

[Steven Johnson]

Quality Quorum wrote:
> 
[SNIP]
> 
> > Anyway, discussion about the morality of the GPL are not appropriate
> > to this mailing list.  Concrete questions about the licensing
> > implications of using Gdb remote stubs, probably ok, I guess.
> 
> It was you idea to discuss this matter under this angle. I had
> a very simple question I would like to be either firmly confirmed or
> firmly denied. If I have i386-stub.c (which is public domain) linked with
> my evil-proprietary-system then it will be breach of GPL 3.0 to debug
> my evil-proprietary-system with GDB using GDB remote protocol.
> 
My take is that as long as you do not ship your final product with
i386-stub.c in use, then there is no GPL violation.  As far as I
understand from my reading of the GPL the only requirement is that you
distibute (or have available on request) source to GPL programs and
programs that incorporate GPL Licenced code.  If i386-stub.c is only
used for development and never with the intent of giving your program
features once released then its use would not constitute a breach of the
GPL in Law or in Spirit.

As far as discussing this on the GDB list, I think it is appropriate and
Necessary.  I agree it should not become a philosophical debate.  We
still have two fairly major questions that need answering:

1.  Does using the RSP require the program using it be a GPL Program? 
   My Take: Id be surprised if this was so. (unless you used a GPL Stub
and distributed your program with it included).
2.  Does linking GDB to Closed Source proprietary libraries constitute a
GPL Violation.
   My Take: Yes it does.

Of these I think question 2 is the most important and needs to be put to
bed before V5.1 of GDB is released.  If they turn out to be GPL
Violations then something should be done to rectify them by their
contributors.  

Whatever the final answer is to Question 2, it needs to be documented in
lay terms for future contributors, so that the rules (and line in the
sand) are clear.

Steven Johnson

Re: Where is GDB going

[Peter Reilley]

I think that there are some good points here.


-----Original Message-----
From: Steven Johnson <sjohnson@neurizon.net>
To: Quality Quorum <qqi@world.std.com>
Cc: GDB Discussion <gdb@sources.redhat.com>
Date: Sunday, February 25, 2001 6:48 PM
Subject: Re: Where is GDB going


>Quality Quorum wrote:
>>
>>
>> However, I had a short but unpleasant private discussion with RMS about
>> GPL 3.0 from which I concluded (1) that it may preclude proprietary
>> software debugging with future versions of GDB by closing protocol
linking
>> loophole in GPL 2.0,
>
>Im guessing that you mean linking to a GPL Program, that is necessary
>for  your program to work, using a communication protocol (say, on top
>of TCP/IP) instead of binary linking (say, using a loadable/linked
>library) would imply that the connecting program needs to be GPL?
>
>This does not make sense, and given the history of the FSF and the GPL
>where they created free alternatives to commonly available Unix
>Utilities (some of which could inter-communicate using comms protocols)
>is also paradoxical.  If this was the case then if Samba used GPL3.0
>then you would not be able to share files with MS Windows unless MS
>Windows was GPL!!  Bye Bye Samba :(  I Must have misunderstood what you
>mean here, could you explain what this loophole is?
>
>> (2) that it will be for sure impossible (and it is
>> may be illegal right now) to link gdb with proprietary software driving
>> various hardware probes.
>I Agree with this.  There are way too many vendors making Windows DLL's
>for their proprietary debug Hardware, and cluttering GDB with Hooks to
>those DLL's.  This is (in my opinion) a clear brach of the GPL (in
>spirit if not in word).  These vendors are riding off the back of the
>work done by and for the FSF without contributing anything back.  And in
>some cases these vendors are obstructionist in even allowing people to
>write properly GPL'd alternatives to their Closed Windows DLL.  I don't
>think it should be allowed, or supported by the GDB community and Any
>patches to GDB that do this trick should be rejected out of hand. See
>ser-ocd.c and v850ice.c (in alphabetical order) for examples of this in
>the current GDB source.  These vendors should either open up their
>direct interfaces to their debuggers or they should not expect a free
>debugger in GDB.  This is a classic "Free as in Beer" not "Free as in
>Freedom" situation.  There are also other Vendor specific versions of
>GDB with similar closed interfaces.


There really is no need for including interfaces to targets that do not
have GPL'ed monitors in the gdb standard source tree.   They are of
no use unless you have bought the hardware.   On the other hand if
we eliminate all such interfaces they there may be only a few
interfaces left, which would decrease the value of gdb for everyone.

If you are suggesting that gdb cannot be used with these proprietary
devices at all then gdb fails in one of the GNU ideals, that is to provide
free tools that replace commercial products.

This is a fine line to draw.   Is communicating to a proprietary
monitor OK if it is by ASYNC or TCP/IP but not if it is by
way of a library?   This is a subject that it is easy to get
religious about.   Unfortunately, at the end of such wars
most people are dead.   If we can accommodate the feelings
and needs of everyone in this community then we will
make progress together.   I say, strip out the proprietary
interface code and allow the manufacturers to provide their own
GPL'ed patched that satisfy their needs.   That should
keep most people happy.

Pete

Re: Where is GDB going

[Steven Johnson]

Peter Reilley wrote:
> 
> This is a fine line to draw.   Is communicating to a proprietary
> monitor OK if it is by ASYNC or TCP/IP but not if it is by
> way of a library?  

The prime distinction I see is that communicating via ASYNC or TCP/IP is
System Neutral. I can as easily communicate using TCP/IP from Solaris as
I can from Windows or Linux.  There is no impediment to anyone using
this interface on a device.  Using a proprietary library forces a user
of GDB to use Windows or Nothing.  (The only current examples of this I
find involve Windows DLL's)  It allows a Hardware Vendor to force a
choice of OS on a GDB user because it is not supported otherwise.  GPL
Code should allow one to support themselves, proprietary libraries
prevent this, published communications specs do not.  Im not religiously
fervent about this issue, but I think the distinction is pretty clear. 
The two examples in GDB's code I cited are the only examples of it I
could find.  Apart from increasing choice I feel that closed source
DLL's linked to GDB decrease choice.  If those vendors want GDB to work
with their hardware then they should do it properly and not force people
to use the vendors OS of choice.

> This is a subject that it is easy to get
> religious about.   Unfortunately, at the end of such wars
> most people are dead.   If we can accommodate the feelings
> and needs of everyone in this community then we will
> make progress together.   I say, strip out the proprietary
> interface code and allow the manufacturers to provide their own
> GPL'ed patched that satisfy their needs.   That should
> keep most people happy.

I Agree totally.
> 
> Pete

Steven.

Re: Where is GDB going

[Quality Quorum]

> 
> There really is no need for including interfaces to targets that do not
> have GPL'ed monitors in the gdb standard source tree.   They are of
> no use unless you have bought the hardware.   On the other hand if
> we eliminate all such interfaces they there may be only a few
> interfaces left, which would decrease the value of gdb for everyone.

Yep, if the cost of linking with GDB is a (at least partial) disclosure 
of intellectual property, nobody would do it. 

Actually, situation will be even worse once protocol "loophole" is 
closed. I highly doubt that it will be possible to talk GDB remote
protocol to a proprietary target at all.

> Pete

Thanks,

Aleksey

Re: Where is GDB going

[Peter Reilley]

>Peter Reilley wrote:
>>
>> This is a fine line to draw.   Is communicating to a proprietary
>> monitor OK if it is by ASYNC or TCP/IP but not if it is by
>> way of a library?
>
>The prime distinction I see is that communicating via ASYNC or TCP/IP is
>System Neutral. I can as easily communicate using TCP/IP from Solaris as
>I can from Windows or Linux.  There is no impediment to anyone using
>this interface on a device.  Using a proprietary library forces a user
>of GDB to use Windows or Nothing.  (The only current examples of this I
>find involve Windows DLL's)  It allows a Hardware Vendor to force a
>choice of OS on a GDB user because it is not supported otherwise.  GPL
>Code should allow one to support themselves, proprietary libraries
>prevent this, published communications specs do not.  Im not religiously
>fervent about this issue, but I think the distinction is pretty clear.
>The two examples in GDB's code I cited are the only examples of it I
>could find.  Apart from increasing choice I feel that closed source
>DLL's linked to GDB decrease choice.  If those vendors want GDB to work
>with their hardware then they should do it properly and not force people
>to use the vendors OS of choice.


There are two separate issues here; the channel of communication to
the target and the language (API) used to communicate with the target.
ASYNC, TCP/IP, library, pipes, etc; are all channels.   The content of the
communication is the language.

ASYNC and TCP/IP are widely available on different OS's.   Libraries
are less widely available and need to be ported.   OCD, one of your
examples, is available on Windows, Linux, and Solaris.  Manufacturers
have every incentive to support as many systems as possible but they
are generally limited in the resources that they can devote to the effort.

The language is generally proprietary, while there is probably a
public spec describing the language, the code in the target is not
open and not GPL'ed.

Gdb supports a number of channels of communication and a number
of different languages (API) of communication.

I don't think that you can distinguish between ASYNC and TCP/IP
on one hand and library calls on the other.   After all, ASYNC and
TCP/IP are library calls on most systems.   On commercial
systems those libraries are not GPL'ed.

If you object to gdb talking a proprietary  language to the target
then that is a reasonable line to draw.   The problem being that
most of them are proprietary.

In more general terms, I don't think that companies getting a "free
ride" off GPL'ed code is such a bad thing.   Yes, they may make some
money off it, but they contribute to it as well in terms of bug fixes
and additional GPL'ed code.   Should we cheer that IBM is
touting Linux and GPL'ed code?   I think that we should!

Pete.