This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Bug with using __interrupt_stack and Redboot to debug
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