[ECOS] gdb vs. eCos?

Jesper Skov jskov@cygnus.co.uk
Wed Feb 17 10:41:00 GMT 1999

>>>>> "Kerry" == Kerry S Kimbrough <kerry@cae-plus.com> writes:

>> Also, using a simulator for debugging the interrupt handlers can be
>> a great help since it doesn't trash so much state as the gdb stub
>> does (that is, debugging in a SIM is truly transparent for the
>> program being run -- at least I haven't had any problems).

Kerry> Interesting comment, Jesper. Can you explain a bit more?

Kerry> Are you describing a SIM(ulator) that provides a debugging
Kerry> capability independent and different from gdb? If so, are you
Kerry> referring to a specific SIM? Can you describe a bit more about
Kerry> what it does? What is the "SIM way"?  Does the SIM run together
Kerry> with gdb, or are they mutually exclusive? What is the
Kerry> relationship between the SIM and the gdb stub?

Sorry, my description may have been a bit vague. I'll try a bit

When using GDB to debug software on a target board, you rely on the
GDB stub on the board to communicate information back to GDB on the
host computer. 

Given that the stub runs on the target, there are some limitations
imposed on it; for example, you cannot put breakpoints or single step
through the trap vector code, since the GDB stub is using this
exception vector to manage the breakpoints in the first place.

By the same token, you cannot put a breakpoint at the start of an
interrupt vector because CPU state will be lost when it is hit;
specifically for the PowerPC, the contents of SSR0 and SSR1 has not
yet been saved by the interrupt vector code. When the breakpoint is
hit, the contents of SRR0 and SRR1 is overwritten, losing all
information about the CPU's state prior to the (original) interrupt.
(got all that? :)

When you are using the simulator instead, no GDB stub is required. All
of GDB's interaction with the "target" happens through magic hooks in
the simulator (I think). This means that (in theory anyway) no state
should ever be lost due to conflicts between GDB stub code and the
application code. This in turn allows you to debug interrupt and
exception vectors without problems.

When you build the eCos tools, the simulator is built as a library
that is used both by a standalone program (powerpc-eabi-run) and by
GDB (I think). There are some examples in the documentation of how to
connect to the simulator from GDB.


More information about the Ecos-discuss mailing list