Re: [ECOS] Bug with using __interrupt_stack and Redboot to debug

[John Newlin <jnewlin at rawbw dot com>]

On Thu, 12 Aug 2004, Bart Veer wrote:

> >>>>> "John" == John Newlin <jnewlin@rawbw.com> writes:
>
>     John> When Redboot starts it is running of the interrupt stack.
>
>     John> When gdb connects to Redboot, and loads an app, a new stack
>     John> is created at the end of memory, and a switch to that stack
>     John> occurs, and the loaded programs runs from that stack. And
>     John> Life is good!
>
>     John> When GDB creates an async interrupt (aka control-c), this
>     John> eventually leads to the running of the
>     John> default_interrupt_vsr. If compiled with
>     John> CYGIMP_COMMON_INTERRUPT_STACK, there is some code that
>     John> checks if the current sp, is in the stack pointer range. If
>     John> the current sp is on the interrupt stack, room is made for
>     John> the new frame, otherwise, the sp is set to the stack top.
>
>     John> The problem (at least for me), is that (anyone still
>     John> reading?) because Redboot was running off of that
>     John> _interrupt_stack originally, the interrupt routines destroy
>     John> what was saved on the stack. When the GDB session ends,
>     John> Redboot attempts to return, however, due to its stack being
>     John> written over, this almost always ends up badly.
>
>     John> Hmm, maybe this because of the completely whacky way that we
>     John> are handling control-c for Xtensa, or maybe it's a general
>     John> problem. Any comments? Does hitting control-c on other
>     John> archs, and then killing gdb leave you a working redboot
>     John> (assuming the hardware is left in a sane state)?
>
> The general assumption is that once you have started running
> application code you can no longer return directly to RedBoot. That
> application may have done all kinds of horrible things to the
> hardware, and overwriting stacks is only a small part of the problem.
> The only way to safely get back to RedBoot is a reset, either a hard
> reset or a soft reset as per the HAL_PLATFORM_RESET() operation. The
> assumption is that the platform HAL knows enough about the various
> devices on the board and hence HAL_PLATFORM_RESET() can put them all
> back into a safe mode.
>
> Now, ideally quitting the gdb session would initiate such a reset. For
> reasons I don't entirely remember, but related to the defined
> semantics of the gdb remote protocol, this could not be the default
> mode of operation. Instead you have to explicitly request this mode of
> operation, by performing a gdb "maintenance packet r". I tend to use
> a macro in my .gdbinit file to take care of this:
>
>   define done
>     maintenance packet r
>     kill
>     quit
>   end
>
> If this does not do the right thing for you then you would have to
> check the HAL_PLATFORM_RESET() definition for your platform.
>
> Bart


Thanks for the clarification Bart.  I do agree with you that a reset
between runs is the right thing to do, however I did fix the Xtensa port
so you can return to Redboot, for no good reason other than I could.  And
yeah, I know it won't work if the user has monkeyed around with the
hardware on-chip and on board that Redboot doesn't know about.


-john

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