This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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
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).




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]