This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Thread-aware debugging w/ Redboot on ARM?
- From: Grant Edwards <grante at visi dot com>
- To: "Paul D. DeRocco" <pderocco at ix dot netcom dot com>
- Cc: Alex Schuilenburg <alexs at ecoscentric dot com>, eCos Discuss <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 7 Dec 2004 13:26:29 -0600
- Subject: [ECOS] Re: Thread-aware debugging w/ Redboot on ARM?
- References: <41B58315.1020107@ecoscentric.com> <NEBBKHCFDGIGIJEHDJFCGEFGMKAA.pderocco@ix.netcom.com>
On Tue, Dec 07, 2004 at 10:46:18AM -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.
> 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.
> As I understand it, GDB sends out fairly high-level remote
> debugging commands, prefixed with dollar signs and
> checksummed, and there are specific commands for dealing with
> threads, so that GDB doesn't have to know the thread structure
> layout. Redboot understands these commands, and knows how to
> manipulate eCos threads.
Sort of. Redboot _itself_ doesn't know the thread structure
layout. Redboot knows how to make eCos system calls into
the eCos kernel which _does_ know how to manipulate threads.
> A JTAG debugger could have similar support built in, but the
> one I've got doesn't.
Yes. In theory it could.
--
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