[ECOS] Calling exit in a Redboot standalone Arm program

Mark Salter msalter@redhat.com
Fri May 2 13:46:00 GMT 2003

>>>>> Pierre Habraken writes:

> Mark Salter wrote:
>> [...]
>> > BTW, Mark, you expressed in an other message some doubts about
>> > the use of HAL_THREAD_* macros. What about the patch as it was
>> > proposed by Jonathan ?
>> I'm just concerned that the CYGACC_CALL_IF_MONITOR_RETURN call will
>> not work from an exception context on all architectures. It will
>> work for ARM, but I believe there are others where it won't work.
>> I'm thinking of architectures like sparc where there are explicit
>> instructions used to return from exceptions. Since, the call to
>> CYGACC_CALL_IF_MONITOR_RETURN from the exit code is in an exception
>> context, the HAL_THREAD_LOAD_CONTEXT macro used by return_to_redboot()
>> may not do the right thing.

> But HAL_THREAD_LOAD_CONTEXT is just a wrapper for
> hal_thread_load_context (defined in context.S), isn't it ?
> I'd expect that the corresponding assembly code of each supported
> architecture (including sparc) has been designed for returning from an
> exception state. Unfortunately my knowledge of the sparc arch. is
> limited and I am not able to check what actually is done in
> hal_thread_load_context for that arch. From what I know, one should find
> there a 'rett' instruction somewhere at the end of the subroutine.
> Instead I found a 'retl' instruction mnemonic which one is not
> documented in the only one sparc guide I have at hand...

for thread switching by the kernel. It is assumed that they will be
used from a thread context, not an exception/interrupt context. Sparc
was just off the top of my head. Others that use special return from
exception instructions are i386, frv, ppc, etc.

> On an other hand, I understand that HAL_THREAD_LOAD_CONTEXT is called
> for returning from the stubs to RedBoot. I thus do not see what
> difference it makes that it returns to the main loop or to the 'do_go'
> procedure. But here too I have certainly misunderstood some pieces of
> the whole stuff...

No. The current use is to return from an application lauched by the go

> Anyway, the question is: as regards the changes applied to cyg_start()
> in main.c that we are considering here, should from your point of view
> these changes be conditionally compiled, or not ?

They don't necessarily need to be conditionally compiled, but it does
need some tweaking. You need to support the HAL_ARCH_PROGRAM_NEW_STACK
case instead of switching to breakpoint directly. Use something like:

static void
                breakpoint();  // Get GDB stubs started, with a proper environment, etc.

I still believe the approach of using CYGACC_CALL_IF_MONITOR_RETURN from
the stub exception context is fundamentally flawed. The way it should
work is to have a little trampoline function like this:

return_from_stub(int exit_status)

The exit code could then use:

   set_pc ((target_register_t)return_from_stub);

so that the normal exception return path can run before the call to


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

More information about the Ecos-discuss mailing list