This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug with using __interrupt_stack and Redboot to debug


>>>>> "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

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]