Subject: Re: gdb, gdbtk, embedded target
From: Stan Shebs <[email-masked]>

28 Oct 1997 10:57:02 -0800
Message-ID: <[email-masked]>
References: <19971027160043063.AAA199.cygnus.gnu-win32@tobi>
X-Newsreader: Gnus v5.3/Emacs 19.34

[email-masked] (Rischer Tobias) writes:

> * Is there anybody using gdbtk for cross-debugging (to embedded
>   target)?  How is your experience?  The tcl interface seems to be a
>   bit shaky yet, at least to me.

The existing gdbtk certainly isn't ideal.  Cygnus has recently
developed a new version of the gdbtk interface, as part of its
"Foundry" IDE (see the Cygnus home page for some screen shots and
such).  It hasn't been released yet though.

> * Would debugging a Motorola CPU32 via BDM be supported, if I had the
>   serial connector from Macraigor Systems?  The friendly person from
>   Macraigor was not sure.  (How came this connector to be the
>   standard?  Is its interface documented somewhere publicly?)

We haven't been testing the 68k + wiggler combination recently, since
we've been working on the PowerPC target instead.  It may very well
have bit-rotted.  The connector's hardware-software interface is
actually private, GDB's backend just makes calls to a DLL that does
the communication.  Craig's API is not published but effectively
public, since you can look at GDB's code that uses it.

Macraigor-type connectors have become standard because Craig Haller
has been the designer for many of those in existence, going back at
least to the P&E BDM connectors...

> * Is there active development of the (GUI part of the) tool going on?
>   Is it part of or co-evolving with the gdb mainstream?  How could I
>   contribute to make gdbtk more stable and functional?  (Having quite
>   some experience with GNU tools and programming in general, but
>   little with Tcl/Tk and the internals of gdb, to be frank).

There are two parts of the GUI that could be worked on.  One is the
tcl code proper, but the current code is basically a dead end.  The
other is gdbtk.c, which is the gdb-tcl connection.  Improvements here
will help both the old and new GUIs, and in our current in-between
state, that would be the most interesting area to work on.  For instance,
handling for various kinds of signals and interrupts is still shaky,
and any improvements would be most helpful.

							Stan Shebs
							Cygnus Solutions
							[email-masked]