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

["Peter Reilley" <micrio at mv dot com>]

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.