[ECOS] Bug with using __interrupt_stack and Redboot to debug

John Newlin jnewlin@rawbw.com
Wed Aug 11 23:07:00 GMT 2004

When Redboot starts it is running of the interrupt stack.

When gdb connects to Redboot, and loads an app, a new stack is created at
the end of memory, and a switch to that stack occurs, and the loaded
programs runs from that stack.  And Life is good!

When GDB creates an async interrupt (aka control-c), this eventually leads
to the running of the default_interrupt_vsr.  If compiled with
CYGIMP_COMMON_INTERRUPT_STACK, there is some code that checks if the
current sp, is in the stack pointer range.  If the current sp is on the
interrupt stack, room is made for the new frame, otherwise, the sp is set
to the stack top.

The problem (at least for me), is that (anyone still reading?) because
Redboot was running off of that _interrupt_stack originally, the interrupt
routines destroy what was saved on the stack.  When the GDB session ends,
Redboot attempts to return, however, due to its stack being written over,
this almost always ends up badly.

Hmm, maybe this because of the completely whacky way that we are handling
control-c for Xtensa, or maybe it's a general problem.  Any comments?
Does hitting control-c on other archs, and then killing gdb leave you a
working redboot (assuming the hardware is left in a sane state)?


-John Newlin

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

More information about the Ecos-discuss mailing list