This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project. See the eCos home page for more information.


[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

[ECOS] Re: ECOS Re: ICE support



>>>>> "Kenneth" == Kenneth Porter <kenneth_porter@kensingtonlabs.com> writes:

    Kenneth> [I'm echoing this back to the list, as I think it's
    Kenneth> something of general interest. My comments follow. - Ken]

    <snip lots of text which has already been posted>

    Kenneth> While I mentioned ICE vendors up above, I was really
    Kenneth> talking about the debuggers they provide with the ICE.
    Kenneth> And of course, vendors call BDM probes an ICE, so the
    Kenneth> terminology suffers from marketing fuzz. However, my
    Kenneth> concern is that I want to use a high-end ICE with
    Kenneth> realtime trace and, if RTOS awareness is important in a
    Kenneth> debugger, I want the debugger that comes with that ICE to
    Kenneth> be aware of the RTOS I choose.

    Kenneth> I expect that gdb already knows how to talk through a
    Kenneth> BDM, but I'm wondering which ICE manufacturers have gdb
    Kenneth> support for their more-sophisticated devices?

    Kenneth> So far I've used Sophia, which used a proprietary
    Kenneth> CodeView-like debugger, and Applied Microsystems'
    Kenneth> SuperTap, which uses the Borland debugger adapted by
    Kenneth> Paradigm for use with an ICE. Neither vendor appeared
    Kenneth> very open to revealing details of their host protocol, so
    Kenneth> any user innovation was limited to using the provided
    Kenneth> debugger scripting feature. (At the time I bought the
    Kenneth> Sophia, I would have preferred an Orion, as it came with
    Kenneth> source to its Forth-based controller, but the device
    Kenneth> lacked adequate overlay memory.) My experience with these
    Kenneth> two vendors leads me to wonder which ICE vendors are
    Kenneth> willing to open their host protocols to the open source
    Kenneth> community.

Warning: I am not an expert on gdb internals, nor do I know a lot
about the marketing side of gdb work.

If gdb provides a better debugging environment than any proprietary
solution, whether because of built-in knowledge of eCos or for any
other reason, then customer demand should cause the ICE vendors to
move away from proprietary solutions and towards the open source
community, as is happening in many other areas of the computing
industry. 

    Kenneth> Can you expand more on your last paragraph? What effect
    Kenneth> does an RTOS have on the debugger?

As with other parts of the embedded systems industry, the problem is
the very wide variety of hardware that has to be supported. gdb has to
cope with many different processor architectures, not to mention
different source languages, object formats, debug formats, host
machines, and similar issues. Then it also has to deal with many
different ways of interacting with the actual hardware. A common
development system involves just a serial line between the host and
the target, with some sort of stub code running on the target side to
provide the necessary support. Communication will be slow so the
system has to be designed to avoid unnecessary data transfers. The
stub code may be embedded in the application itself, or in a ROM
monitor provided by Cygnus, or in a third party ROM monitor. In the
case of a third party ROM monitor this may use the standard gdb
protocols for debugging or it may use its own protocol. Instead of a
serial line a faster transport such as ethernet might be used.
Or the user might have special debug hardware, such as BDM or ICE.

Providing all of this in a single debugger is not trivial, and makes
things much more interesting than a workstation debugger. At times a
creative solution is needed. If you will excuse a commercial plug, a
good example of this is the Introspect technology: this provides
tracing with low overheads and no special hardware. See
http://www.cygnus.com/news/introspect.html for more details.

Bart Veer // eCos net maintainer