ECOS Re: ICE support

[Kenneth Porter]

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

On Thu, 19 Nov 1998 19:02:41 GMT, Bart Veer wrote:

>>>>>> "Kenneth" == Kenneth Porter <kenneth_porter@kensingtonlabs.com> writes:
>
>    Kenneth> On Wed, 18 Nov 1998 21:27:07 GMT, Bart Veer wrote:
>    >> Generally anything related to debugging is a gdb issue rather
>    >> than an eCos issue. If gdb already has support for an existing
>    >> ICE then debugging an eCos-based application would not be any
>    >> different than debugging any other application. If gdb does not
>    >> yet have support for a particular ICE then the ICE vendor or
>    >> the user can add this themselves, since gdb is of course open
>    >> source. Alternatively Cygnus will provide porting services for
>    >> gdb as we do for our other tools.
>
>    Kenneth> My concern arose when I was at ESC98 and I noticed ICE
>    Kenneth> vendors advertising support for specific RTOS's. It
>    Kenneth> seemed to be a marketing feature that the debugger was
>    Kenneth> RTOS-aware, and able to directly manipulate and display
>    Kenneth> task state.
>
>This sort of thing does not need an ICE. It basically requires some
>means of transferring memory contents from the target to software in
>the host. The information transfer can be done by any means: serial
>line, ethernet, ICE, whatever, it is just that some of the mechanisms
>are more intrusive than others. The host software also needs to have
>access to symbolic information in the executable so that it can
>associate data structures with locations in memory. It is possible to
>do this sort of thing in the debugger itself, or in a separate
>process. We are well aware of the technical issues involved and have
>various plans, it is all a case of priorities and available resources.
>
>    Kenneth> Some debugger vendors (eg. SDS) supply an RTOS API to add
>    Kenneth> RTOS awareness for a previously-unsupported RTOS, so eCos
>    Kenneth> awareness could be added by a 3rd party in those cases.
>
>That would certainly be possible. Cygnus' preferred approach would of
>course be to enhance gdb so that provides all the appropriate
>facilities and the various ICE's. If any of our users prefer to take a
>different approach then they are completely free to do so.
>
>I should point out that there are a few complications. Because eCos is
>such a configurable system a lot of the kernel's data structures are
>not as rigid as in other systems. Teaching a debugger about the data
>structures used for the mlqueue scheduler does not help if the user
>has configured the system for a bitmap scheduler instead.
>
>    Kenneth> I've not used an RTOS before, so I don't really know how
>    Kenneth> an RTOS-aware debugger is different from a debugger used
>    Kenneth> with a single-threaded app. I expect that it's similar to
>    Kenneth> the ability to select different threads in my desktop
>    Kenneth> apps and operate on the selected thread's stack
>    Kenneth> variables.
>
>That is one very important aspect. There are many other issues as
>well, for example the numerous different ways in which host and target
>interaction can happen. A crucial factor is performance: on a desktop
>machine scanning another process' address space is generally
>straightforward; doing the same thing over a serial line can be
>unpleasant.
>
>Bart Veer // eCos net maintainer

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

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

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

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


Kenneth Porter
Kensington Laboratories, Inc.
mailto:kenneth_porter@kensingtonlabs.com
http://www.kensingtonlabs.com