[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cygwin Insight debugger for 68k
- Date: Mon, 28 Feb 2000 09:25:30 -0500
- From: charles.gauthier at nrc.ca (Charles-Antoine Gauthier)
- Subject: Cygwin Insight debugger for 68k
Gus Paolone wrote:
> Hi all;
> I apologize if this message is not directly related to RTEMS issues. I
> have finally got a gdb monitor going on a 68360 target (needs some
> cleaning) and I can connect to it with gdb over a serial line. I have
> tried ddd compiled for Cygwin but it seems too slow. I downloaded
> Insight from Cygwin but its compiled for x86. Does anybody use it for
> 68k? If so how can I get my hands on it?
> Please note that I'm working on Win98 and Cygnus tools.
> Any help would be greatly appreciated.
> Gus Paolone.
We use ddd on 550 MHz Pentium-III Linux boxes. Like you, we connect to
the target through a serial line.
In our case, gdb is having a conversation with the onboad ROM debugger,
167Bug. It is slow. The problem is that ddd is issuing commands to gdb
to update its view of the target state on each breakpoint. In response,
gdb issues a number of commands to 167Bug. The response is slow partly
because it contains a lot of extraneous characters meant for humans that
gdb must strip out before it processes the data. At 9600bps, this just
takes time, particularly if the machine code window needs to be updated.
I wouldn't expect the speed to be significantly better with a gdb stub.
Essentially, the same protocol is used. There may be less extraneous
characters, but then again, more trips may be required to collect the
data. We never tried it, so we do not know for sure what the speed
difference would be.
I don't see why Insight would be any faster. What you need to do is
speed up the link between the host and the target. If you have some
means of monitoring the traffic between the host and target, do so. It
is quite instructional to watch the data stream. You will see why it
takes almost forever for ddd to come back after you hit step, next, or
continue until the next breakpoint.
Software Engineering Group
Institute for Information Technology
National Research Council of Canada
Ottawa, ON, Canada