RE: [ECOS] stub-building

[Gary Thomas <gthomas at redhat dot com>]

On 27-Apr-00 Paul Kinzelman wrote:
> I've created a list of source files and a TAGS emacs
> file so I can find my way around the files, but I was
> hoping for some 'big picture' information, like how
> the gdb stub interacts with the program it's debugging?
> Like how does it not get in the way of the next level
> of software running on the same system?
> 

In general, this is treated in an either/or fashion.  When the stubs
are running, they control the machine completely.  They communicate
with the GDB host interface to do it's bidding.  Once control is passed
to the program (via GDB 'continue' command), the stubs hand the machine
over to the program.  Only if something extraordinary happens, like a 
breakpoint, do the stubs get [re]involved.

If your eCos program has builtin stubs then they sit on the sidelines
once the program and manage things when GDB interaction is required.

As far as the basic stubs go, they use virtually no hardware resources
other than the serial port.  In the simplest case, this is only polled
and then only when GDB interaction is required.  Some stubs, and application
builtin stubs, can enable ^C handling which will then set up the debug
serial port to use interrupts so that the ^C can be handled asynchronously
while the program runs.

> Also, any comments on the problem of specifying the
> baud/port and having the downloader hang? It's very
> repeatable.

What system/version (Linux?) are you running?  I'm quite sure I've
done this before and it worked.  It sounds like it might be a driver
problem - there is nothing special in the code about what device one
might be using.

There are a couple of things to look at here:
  * The code is very ugly.  I adapted it from a very hacky DOS(!) 
    program that Cirrus Logic uses.  There are spin-loops used for
    timing, etc.  Try looking at the "io.c" file and increasing the
    loop count [slightly] to see what happens.
  * Related to the above - the command line interface is terribly crude.

Patches and/or improvements are of course always welcome :-)

> -PaulK
> 
> -----Original Message-----
> From: Jesper Skov [mailto:jskov@redhat.com]
> Sent: Thursday, April 27, 2000 12:11 AM
> To: Paul Kinzelman
> Cc: ecos-discuss@sourceware.cygnus.com
> Subject: Re: [ECOS] stub-building
> 
> 
>>>>>> "Paul" == Paul Kinzelman <PaulK@isdcorp.com> writes:
> 
> Paul> I'm interested in understanding a bit more about the stub to try
> Paul> to integrate it with some low-level loader/BIOS code we've got
> Paul> here for another purpose. Are there any writeups about the
> Paul> structure of the code? When I build it, I see a bazillion files
> Paul> scroll past the screen, but many seem related to libraries. Are
> Paul> there hopefully just a handfull of sources that do all the work?
> 
> The stubs are defined by files in hal/common/<version>/src and some
> architecture and platform specific file in each CPU directory (look
> for files named *stub*).
> 
> Jesper
>