This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Calling exit in a Redboot standalone Arm program
- From: Pierre Habraken <Pierre dot Habraken at imag dot fr>
- To: Mark Salter <msalter at redhat dot com>
- Cc: jifl at eCosCentric dot com, ecos-discuss at sources dot redhat dot com
- Date: Mon, 05 May 2003 14:51:02 +0200
- Subject: Re: [ECOS] Calling exit in a Redboot standalone Arm program
- Organization: Université Joseph Fourier
- References: <3EA53C1E.231D1898@imag.fr> <20030422132718.70DE07885A@deneb.localdomain> <3EA5646A.5CF9F526@imag.fr> <3EA5B1B8.8020205@eCosCentric.com> <20030423020915.A942A7885A@deneb.localdomain> <3EA74B92.1050107@eCosCentric.com> <3EB13580.9E282799@imag.fr> <20030501153204.149EE7885A@deneb.localdomain> <3EB26787.FBE78A28@imag.fr> <20030502134642.A82A77885A@deneb.localdomain>
I just realized that thread/context switching in eCos is not
interrupt/exception driven (as opposed to how it's done in a Unix like
OS)...
Things are a bit clearer to me now. I've applied the code changes you
suggest (I'll send corresponding patch to ecos-patches) and done some
successful tests. Have you an idea about which tests among those
provided with the eCos distribution are more significant as regards
these changes ?
Pierre
Mark Salter wrote:
>
> >>>>> 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...
>
> HAL_THREAD_LOAD_CONTEXT and HAL_THREAD_SWITCH_CONTEXT are macros used
> 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
> command.
>
> > 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
> call_breakpoint(void)
> {
> #ifdef HAL_ARCH_PROGRAM_NEW_STACK
> HAL_ARCH_PROGRAM_NEW_STACK(breakpoint);
> #else
> breakpoint(); // Get GDB stubs started, with a proper environment, etc.
> #endif
> }
>
> 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:
>
> void
> return_from_stub(int exit_status)
> {
> CYGACC_CALL_IF_MONITOR_RETURN(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
> CYGACC_CALL_IF_MONITOR_RETURN is made.
>
> --Mark
--
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss