Re: ser-ocd.c gone! What now?

Re: ser-ocd.c gone! What now?

[Peter Reilley]

This is a thread that was discussed here a while ago.   It is
a hot button issue for many.


-----Original Message-----
From: Peter Ryser <Peter.Ryser@xilinx.com>
To: gdb@sourceware.cygnus.com <gdb@sourceware.cygnus.com>
Date: Tuesday, July 31, 2001 1:59 PM
Subject: ser-ocd.c gone! What now?


>Hi everybody,
>
>with some astonishment I noticed that ser-ocd.c has been removed from
>the GDB sources. I searched the mail archives and read all the
>corresponding messages.
>This mail has 2 parts. In the first part I would like to share my
>thoughts about ser-ocd.c, DLLs and so on, and in the second part I ask
>for some advice how to go on with my current development.
>
>1. ser-ocd.c, DLLs
>Let me first ask a question which I think has not come up in the
>discussion. When ser-ocd.c was removed, did you think of all the
>current Wiggler users who will now not be able to upgrade to newer
>versions of GDB without losing their debugging capabilities?


We had this discussion and some people felt that it should not be there.
We at Macraigor Systems are going to the "remote" daemon because
of this issue.   This seems to be a reasonable compromise.   The
GDB support with ser_ocd.c for PPC and ARM are on the Macraigor
site, www.ocdemon.com   The newer release for the Intel Xscale
processor uses the remote daemon.   The source is there as well.


>About DLLs: when you write a OCD/BDM/JTAG back-end for a debugger you
>need to have internal knowledge of how the processor works. Often you
>can only get this information by signing a NDA. This makes it impossible
>to distribute source code, but you can distribute an executable. This is
>the same thing that happens with graphic cards and X11. I think that the
>X11 community has found a solution for this problem.
>
>IMHO it is dangerous to exclude DLLs. It only results in branches of the
>GDB sources. In the end it is hard for the normal user to find a version
>of GDB that supports what he wants to have.
>
>A DLL itself is only useful with the corresponding cable/hardware. The
>DLL often relies on additional drivers provided by the OS (e.g. parallel
>port). In that sense you could also say that the DLL gets part of the
>operating system as soon as it is installed.


This was well hashed out.   There are even issues as to if it
is OK to run on Windows, Solaris, etc.   They have proprietary OS's,
drivers,
etc.   Is a graphic card driver part of the OS?   A printer driver? Scanner?
Are Windows DLL's OK but not Linux shared lib's.  Etc, etc, etc.   It went
on
for quite a while.

As to GPL, the law is more than just what is written, it is also
precedent.   In this case the precedent is clearly that GDB interfaces
with proprietary debug monitors, propriarity drivers, and propriarity
hardware.   The world is simply not black and white.

>
>2. What now?
>
>I am currently developing a GDB backend for the IBM PPC405. The involved
>HW/SW is: GDB (ser-ocd.c) -> DLL -> cheap cable attached to the parallel
>port -> BDM port of the 405.


The 405 is supported in GDB with ser_ocd.c for Linux, Solaris, and Windows.
It can be gotten from the Macraigor site mentioned above.

>With ser-ocd.c gone (and it probably won't be back in, will it?) I have
>to find a new method to communicate with the processor. As far as I can
>see there is no way to talk to locally attached hardware (cable at
>parallel port). I could use the remote protocol and write a dedicated
>server. This has two disadvantages. First, it is a lot of work. Second,
>it is not really efficient if GDB and the server are on the same host.
>
>Perhaps I'm missing a simple method. If anybody knows of a different
>solution please let me know.
>
>Thanks,
>- Peter
>
>PS: Does anybody know whether somebody else is working on improving GDB
>to use with the IBM PPC405 (e.g. set architecture powerpc:405).


I have done the Linux and Solaris work for Macraigor and that includes the
405.

Pete.

Re: ser-ocd.c gone! What now?

[Peter Ryser]

[..]

> The newer release for the Intel Xscale
> processor uses the remote daemon.   The source is there as well.

Probably, I am looking in the wrong place. I cannot find the source code for
OCDemon. All I can find are the modified source files for GDB (
http://www.ocdemon.com/gdb_mods.tgz ).

[..]

> As to GPL, the law is more than just what is written, it is also
> precedent.   In this case the precedent is clearly that GDB interfaces
> with proprietary debug monitors, propriarity drivers, and propriarity
> hardware.   The world is simply not black and white.

I agree. But - unfortunately - this seems not to be the general opinion...

[..]

> I have done the Linux and Solaris work for Macraigor and that includes the
> 405.

Probably, I am looking in the wrong places again, but I cannot find support for
the 405 neither in the GDB main branch nor in the GDB modifications mentioned
above. The register set for the 405 is different than for the 403. I see no 405
specific register set.

- Peter

Re: ser-ocd.c gone! What now?

[Quality Quorum]

On Wed, 1 Aug 2001, Peter Ryser wrote:

> > I did a similar thing http://world.std.com/~qqi/labslave/rproxy.html
> >
> > I am going to change licensing from GPL to BSD before next monday.
> 
> Thanks for the link. I will have a look at your source code. Can you briefly
> explain why you change licensing terms and what this means (is BSD less
> restrictive)?

BSD is way less restrictive :) .

 
> - Peter

Thanks,

Aleksey
 

Re: ser-ocd.c gone! What now?

[Peter Ryser]

> I did a similar thing http://world.std.com/~qqi/labslave/rproxy.html
>
> I am going to change licensing from GPL to BSD before next monday.

Thanks for the link. I will have a look at your source code. Can you briefly
explain why you change licensing terms and what this means (is BSD less
restrictive)?

- Peter

Re: ser-ocd.c gone! What now?

[DJ Delorie]

> I'm confused. Was the "old" GDB (with ser-ocd.c) and the seperately
> distributed wigglers.dll legally correct?

I'm not sure.  There was some debate about that.

> I am not talking about applications. I am talking about
> drivers. According to your definition you will not be able to use
> GDB with the remote protocol over an ethernet card that comes with
> an extra driver since the driver was not part of the OS.

Except that the ethernet *interface* is a normal part of the operating
system, and that's what gdb is using.  You can expect, for example,
winsock to exist on all windows systems, regardless of the status of
the ethernet driver.  A dll that adds a *new* interface for gdb to use
is not in the same class.

> If I understand this correctly, I can ship a compiled version of GDB
> with the corresponding source code. I also can ship (separately) a
> compiled DLL that does not come with source code (of course not
> under GPL). Is that right?

Um, no.  If the "corresponding source code" you claim is not the
"complete source code" then the GPL won't let you distribute that
binary.  In this case, the source for that dll may be part of the
"complete source code" from the GPL's viewpoint.  Without that, you
have not really shipped the corresponding source code to the *work*
that is gdb+dll.

> I would like to point out that we want to contribute to the open
> source project.

That is good.  Convincing the dll to become open source is a way of
contributing.

> and we would like to integrate them in the main source tree.

That may not be possible if they depend on proprietary code (the dll).

Another idea is to write a dll that converts the proprietary API to
one of gdb's standard APIs, like the remote protocol, so that custom
code is not needed in gdb?

Re: ser-ocd.c gone! What now?

[Quality Quorum]

> 
> I have created just such a server for the MPC860 (not to dissimalr to
> the
> ibm chip you mention, both being powerPC.) To explode some of your 
> misconceptions about just such a server. 1. It was less work than
> hacking 
> GDB because the interface is well defined (less than 1 week of labor for
> me)
> 2. It is no slower than ser-ocd, in fact I believe it is a tad faster.
> 
> It also has the advantage that the debugger does not have to be on the
> same
> computer as the one attached to the device being debugged (as long as
> you
> use TCPIP).

I did a similar thing http://world.std.com/~qqi/labslave/rproxy.html

I am going to change licensing from GPL to BSD before next monday.

> 
> Steven.
> 

Thanks,

Aleksey

Re: ser-ocd.c gone! What now?

[Steven Johnson]

DJ Delorie wrote:
> 
> I answer this only in the context of the GNU GPL...
> 
> > About DLLs: when you write a OCD/BDM/JTAG back-end for a debugger you
> > need to have internal knowledge of how the processor works. Often you
> > can only get this information by signing a NDA.
> 
> The mere fact of the NDA may disqualify that code from any GPL'd
> program.  Being in a separate file (the dll) may not exempt it and
> gdb from being one "work" by legal definitions.
> 

Regarding XFree86, The XFree86 Team do not link to proprietary DLL's.  
They have a driver model, and certain vendors ship non open source 
drivers (like Nvidia).  The other distinction is XFree86 is not 
licenced under the GPL. Further vendors that do protect these debug
interfaces with NDA's are destroying the benefit of implementing them
in the first place (cheap and easy and readily available )

> 
> > With ser-ocd.c gone (and it probably won't be back in, will it?) I have
> > to find a new method to communicate with the processor. As far as I can
> > see there is no way to talk to locally attached hardware (cable at
> > parallel port). I could use the remote protocol and write a dedicated
> > server. This has two disadvantages. First, it is a lot of work. Second,
> > it is not really efficient if GDB and the server are on the same host.
> >
> > Perhaps I'm missing a simple method. If anybody knows of a different
> > solution please let me know.
> 
> The GPL allows this solution - distribute your changes as a patch, in
> source form, without the DLL or base GDB sources.  The GPL only comes
> into affect when you create a binary (either gdb or the dll) *and*
> distribute it, and only applies to GPL'd sources.  If the patch is
> entirely written by you, you can distribute just the patch under other
> terms, as long as it includes *no* original gdb sources or binaries
> built from them.

I have created just such a server for the MPC860 (not to dissimalr to
the
ibm chip you mention, both being powerPC.) To explode some of your 
misconceptions about just such a server. 1. It was less work than
hacking 
GDB because the interface is well defined (less than 1 week of labor for
me)
2. It is no slower than ser-ocd, in fact I believe it is a tad faster.

It also has the advantage that the debugger does not have to be on the
same
computer as the one attached to the device being debugged (as long as
you
use TCPIP).

Steven.

Re: ser-ocd.c gone! What now?

[Peter Ryser]

> I answer this only in the context of the GNU GPL...
>
> > About DLLs: when you write a OCD/BDM/JTAG back-end for a debugger you
> > need to have internal knowledge of how the processor works. Often you
> > can only get this information by signing a NDA.
>
> The mere fact of the NDA may disqualify that code from any GPL'd
> program.  Being in a separate file (the dll) may not exempt it and
> gdb from being one "work" by legal definitions.

I'm confused. Was the "old" GDB (with ser-ocd.c) and the seperately
distributed wigglers.dll legally correct?

[..]

>> A DLL itself is only useful with the corresponding cable/hardware. The
>> DLL often relies on additional drivers provided by the OS (e.g. parallel
>> port). In that sense you could also say that the DLL gets part of the
>> operating system as soon as it is installed.

> The GPL talks about things that are normally considered part of the
> OS.  I doubt anyone could convince a court that a custom
> hardware/software debugging package is a normal part of the OS.

> By your definition, *all* applications become part of the OS when
> installed, as they *all* rely on something from the OS.  Since that is
> a useless legal definition (it doesn't help discriminate), I doubt the
> courts would interpret it that way.

I am not talking about applications. I am talking about drivers. According to
your definition you will not be able to use GDB with the remote protocol over
an ethernet card that comes with an extra driver since the driver was not part
of the OS.


> > With ser-ocd.c gone (and it probably won't be back in, will it?) I have
> > to find a new method to communicate with the processor. As far as I can
> > see there is no way to talk to locally attached hardware (cable at
> > parallel port). I could use the remote protocol and write a dedicated
> > server. This has two disadvantages. First, it is a lot of work. Second,
> > it is not really efficient if GDB and the server are on the same host.
> >
> > Perhaps I'm missing a simple method. If anybody knows of a different
> > solution please let me know.
>
> The GPL allows this solution - distribute your changes as a patch, in
> source form, without the DLL or base GDB sources.  The GPL only comes
> into affect when you create a binary (either gdb or the dll) *and*
> distribute it, and only applies to GPL'd sources.  If the patch is
> entirely written by you, you can distribute just the patch under other
> terms, as long as it includes *no* original gdb sources or binaries
> built from them.

And that's exactly where the branching starts. Get a patch from here, get a
patch from there...

If I understand this correctly, I can ship a compiled version of GDB with the
corresponding source code. I also can ship (separately) a compiled DLL that
does not come with source code (of course not under GPL). Is that right?

I would like to point out that we want to contribute to the open source
project. So all the changes we make to GDB to support the 405 will be
available as source code and we would like to integrate them in the main
source tree. The cable that we use to connect a Windows/Linux PC or Solaris
Workstation will be "open source" (i.e. you can make your own cable). The only
thing that we cannot distribute in source code (at least that's what we
believe at this moment) is the part that translates the GDB commands into
JTAG/BDM bitstreams. This would be available in a DLL as the driver of the
cable. I think that this would be a low cost solution for debugging a 405.

- Peter

Re: ser-ocd.c gone! What now?

[DJ Delorie]

I answer this only in the context of the GNU GPL...

> About DLLs: when you write a OCD/BDM/JTAG back-end for a debugger you
> need to have internal knowledge of how the processor works. Often you
> can only get this information by signing a NDA.

The mere fact of the NDA may disqualify that code from any GPL'd
program.  Being in a separate file (the dll) may not exempt it and
gdb from being one "work" by legal definitions.

> IMHO it is dangerous to exclude DLLs. It only results in branches of the
> GDB sources.

If it is illegal to support a proprietary interface on the trunk, it
will be just as illegal on a branch.  However, it may also be that it
was removed for political reasons - to convince the DLL to be free.
Anyone continuing support for a non-free dll is then doing a
disservice to the gdb community, by making it easy for proprietary
solutions to remain proprietary.

> A DLL itself is only useful with the corresponding cable/hardware. The
> DLL often relies on additional drivers provided by the OS (e.g. parallel
> port). In that sense you could also say that the DLL gets part of the
> operating system as soon as it is installed.

The GPL talks about things that are normally considered part of the
OS.  I doubt anyone could convince a court that a custom
hardware/software debugging package is a normal part of the OS.

By your definition, *all* applications become part of the OS when
installed, as they *all* rely on something from the OS.  Since that is
a useless legal definition (it doesn't help discriminate), I doubt the
courts would interpret it that way.

> With ser-ocd.c gone (and it probably won't be back in, will it?) I have
> to find a new method to communicate with the processor. As far as I can
> see there is no way to talk to locally attached hardware (cable at
> parallel port). I could use the remote protocol and write a dedicated
> server. This has two disadvantages. First, it is a lot of work. Second,
> it is not really efficient if GDB and the server are on the same host.
> 
> Perhaps I'm missing a simple method. If anybody knows of a different
> solution please let me know.

The GPL allows this solution - distribute your changes as a patch, in
source form, without the DLL or base GDB sources.  The GPL only comes
into affect when you create a binary (either gdb or the dll) *and*
distribute it, and only applies to GPL'd sources.  If the patch is
entirely written by you, you can distribute just the patch under other
terms, as long as it includes *no* original gdb sources or binaries
built from them.

ser-ocd.c gone! What now?

[Peter Ryser]

Hi everybody,

with some astonishment I noticed that ser-ocd.c has been removed from
the GDB sources. I searched the mail archives and read all the
corresponding messages.
This mail has 2 parts. In the first part I would like to share my
thoughts about ser-ocd.c, DLLs and so on, and in the second part I ask
for some advice how to go on with my current development.

1. ser-ocd.c, DLLs
Let me first ask a question which I think has not come up in the
discusssion. When ser-ocd.c was removed, did you think of all the
current Wiggler users who will now not be able to upgrade to newer
versions of GDB without losing their debugging capabilities?

About DLLs: when you write a OCD/BDM/JTAG back-end for a debugger you
need to have internal knowledge of how the processor works. Often you
can only get this information by signing a NDA. This makes it impossible
to distribute source code, but you can distribute an executable. This is
the same thing that happens with graphic cards and X11. I think that the
X11 community has found a solution for this problem.

IMHO it is dangerous to exclude DLLs. It only results in branches of the
GDB sources. In the end it is hard for the normal user to find a version
of GDB that supports what he wants to have.

A DLL itself is only useful with the corresponding cable/hardware. The
DLL often relies on additional drivers provided by the OS (e.g. parallel
port). In that sense you could also say that the DLL gets part of the
operating system as soon as it is installed.


2. What now?

I am currently developing a GDB backend for the IBM PPC405. The involved
HW/SW is: GDB (ser-ocd.c) -> DLL -> cheap cable attached to the parallel
port -> BDM port of the 405.

With ser-ocd.c gone (and it probably won't be back in, will it?) I have
to find a new method to communicate with the processor. As far as I can
see there is no way to talk to locally attached hardware (cable at
parallel port). I could use the remote protocol and write a dedicated
server. This has two disadvantages. First, it is a lot of work. Second,
it is not really efficient if GDB and the server are on the same host.

Perhaps I'm missing a simple method. If anybody knows of a different
solution please let me know.

Thanks,
- Peter

PS: Does anybody know whether somebody else is working on improving GDB
to use with the IBM PPC405 (e.g. set architecture powerpc:405).