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


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.

Are you saying that the stub/serial interaction is all done with loops?
So there's no interaction with interrupts at all?

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?

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


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