This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
RE: stub-building
- To: Paul Kinzelman <PaulK at isdcorp dot com>
- Subject: RE: [ECOS] stub-building
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Thu, 27 Apr 2000 09:48:25 -0600 (MDT)
- Cc: ecos-discuss at sourceware dot cygnus dot com
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.