This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: stub-building



On 27-Apr-00 Paul Kinzelman wrote:
> Thanks! Additional comments below...
> 
>>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.
> 
> I'll look more heavily at the files you suggested.
> What I'm looking for are the various stub entrypoints and
> exitpoints and how interrupts are handled (I did notice stub interrupt
> vectors definitions). The gdb stub must manage the swapping of
> interrupt vectors between itself and the next level software?
> I'll look first in the files you suggested before.
> 

The normal case is for these to be shared - the GDB stubs handle the vectors
it needs, eCos handles the rest.  The details differ depending on the platform
and/or architecture.

> Are you saying that the stub/serial interaction is all done with loops?

The comment about loops applies primarily to the download utility.

> So there's no interaction with interrupts at all?
> 

Unless you enable ^C handling, all GDB stub serial I/O is polled.

> My stuff would have to reserve room for the stub and the stack for
> the stub, right? Where in the code does the stub stack get set up?
> 

The stubs normally run on the default system stack.  In the case of the ARM
I know that I added a separate stack just for GDB to use.  Look in 'vectors.S'
to find these details.

>>> 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.
> 
> I'm using Linux RH6.1, 2.2.12-20 on a PC - it's very wierd.
> It's not obvious to me that the cause is due to my
> specifying the device port name - I'm also specifying
> the baud rate (even tho both should be default). I assume the port is
> hooked up right at least initially because Linux knows the board
> has woken up and works fine using defaults. Might be worth trying
> it again on your side just to make sure it still works.
> 
>>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 :-)
> 

> And if I wanted to increase the baud rate to 115200, I'd have to hack both
> the stub and Insight, right, because Insight's pulldown list includes
> only 57KB?
> 

Yup.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]