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

[Gary Thomas <gary at mlbassoc dot com>]

On Tue, 2004-12-07 at 16:16, Paul D. DeRocco wrote:
> > From: grante@visi.com [mailto:grante@visi.com]
> >
> > > 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. If by "target" you mean the eCos system
> plus application that you're debugging, the CPU isn't executing instructions
> from it, is it? 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, 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?

No, you are quite correct.  While GDB/RedBoot is in control, eCos is
completely stopped.

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

Correct, but they do require some level of cooperation (via the virtual
vector table) between the two entities.  This is one thing that makes
thread support via an ICE a challenge.  

> 
> 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 masked.  They will still be there when you resume the
program.  Note: on some hardware (architectures) there are interesting
anomalies here.  If you single step (from GDB) and there are interrupts
pending, some architectures will actually execute the entire interrupt
handling path while on others you may end up stepping into the interrupt
handler code.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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