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

[Grant Edwards <grante at visi dot com>]

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

>>> I'm not sure what you mean by "running target". When I halt an
>>> eCos system with Ctrl+C in GDB, in what sense is the target
>>> still "running"?
>>
>> The CPU is executing instructions.
> 
> Okay, if by "target" you mean the board, then of course the
> CPU is still running, because Redboot is running.

Right.  And redboot knows how to call functions in the eCos
kernel.

> If by "target" you mean the eCos system plus application that
> you're debugging, the CPU isn't executing instructions from
> it, is it?

Based on my reading of the code, when you do thread stuff in
GDB, it sends a command to Redboot, and Redboot calls functions
in the eCos kernel.  So yes, Redboot is executing instructions
from your "eCos system plus application".  I may have
misunderstood something -- if so, somebody please tell me to
shut up.

> I guess what I'm trying to verify is that Redboot works by
> seizing control of the CPU and not allowing anything outside
> of itself to execute,

That's mostly true.

> rather than, say, by putting all the threads into the
> suspended state. To GDB/Redboot, the entire eCos system,
> including its scheduler, looks like a single program, so when
> you're single-stepping, you can single-step right through the
> scheduler, and watch a thread switch happen, if you want. Am I
> mistaken about that?

If you want to, you certainly can.

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

> One final question: when you halt a program via remote
> debugging, are interrupts masked in the CPU, or do interrupts
> continue to be serviced even while Redboot is sitting there
> waiting for a single-step or continue command?

Interrupts are disabled.

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