ECOS Re: ICE support

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

[ECOS] Re: ECOS Re: ICE support

[Bart Veer]

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

ECOS Re: ICE support

[Bart Veer]

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

    Kenneth> Have any ICE vendors indicated support for eCos, probably
    Kenneth> under gdb? I'd want a high-end ICE with real-time trace,
    Kenneth> not just the more-common BDM debugger.

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.

When hardware debug support is not available on a given board and
things like breakpoints have to be implemented in software, there is
an overlap between eCos, the gdb target-side stubs, and possibly the
ROM monitor. The exact details will depend on the target processor,
whether the system is configured for ROM or RAM start-up, etc.

Bart Veer // eCos net maintainer