[ECOS] Re: Thread-aware debugging w/ Redboot on ARM?

Grant Edwards grante@visi.com
Tue Dec 7 23:44:00 GMT 2004


On Tue, Dec 07, 2004 at 03:38:30PM -0800, Paul D. DeRocco wrote:

>>>>> Obviously, there's some Redboot code that waits at the serial
>>>>> or Ethernet port for commands, but isn't the eCos kernel
>>>>> frozen out at that point, so that no instructions are being
>>>>> executed outside of Redboot?
>>>>
>>>> No.  Redboot has the ability via the Virtual Vector table to
>>>> make calls into the eCos kernel to retrieve thread info and (I
>>>> think) do things like lock/unlock the scheduler.
>>>
>>> But those are just subroutine calls to eCos utility functions,
>>> taking place within the Redboot stack, aren't they?
>>
>> I'm not sure what you mean.  RedBoot is calling functions
>> within the eCos scheduler (the one linked with your application
>> code) to access/modify the thread state info in your
>> application.
> 
> Yes, but when it does that, I assume that those scheduler
> functions, whatever they may do to an eCos thread, are running
> in the Redboot stack.

Yes.

> That is, those scheduler functions are nothing more than
> subroutines, so the CPU stack pointer remains pointed into the
> Redboot stack throughout the operation.

Yes, but that doesn't alter the fact that RedBoot is executing
instructions that are outside of itself (they're in your
application), and I thought that's what you were asking about.

> In other words, if I've got this right, to the
> eCos+application system, debugger halts look just like
> hardware interrupts that take a very long time to complete.

It doesn't just "look like" that, it _is_ that.

> And single-stepping looks like a return from an interrupt that
> is followed by a fresh hardware interrupt after one
> instruction.

Again, it is that (at least on all of the platforms I've seen).

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list