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