This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project. See the eCos home page for more information.
>>>>> "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 harder: 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. Cheers, Jesper