[ECOS] Calling exit in a Redboot standalone Arm program

[ECOS] Calling exit in a Redboot standalone Arm program

[Pierre Habraken]

Hello,

I have a question about the way the exit() libc function is dealt with:

With Angel, the native on board debug monitor shipped with the E7T, when
a program calls exit(0) then the control is smoothly given back to gdb:
===========================================================
(gdb) continue
...
Program exited normally.
(gdb)
===========================================================

With the current version of RedBoot, control is given back to gdb by
raising a SIGTRAP signal:
===========================================================
(gdb) continue
...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x000101bc in _exit (stat=8)
    at ../../../../../newlib-1.11.0/libgloss/arm/redboot-syscalls.c:54
54              __syscall(SYS_exit, stat);
(gdb)
===========================================================

These boards together with RedBoot are (will be) used by undergraduate
unexperimented students. The above message displayed by gdb at the end
of program execution is of no use for them and may confuse most of them.
So, I'd like to get gdb+redboot have the same external behavior as
gdb+angel, as far as possible.
I did some investigations and tests that let me think that this goal
could be achieved by applying the modification below to
redboot/current/src/syscall.c:
===========================================================
      ...
      case SYS_exit:
   if (gdb_active) {
       __send_exit_status((int)arg1); <<<<<< new code
       breakpoint();                  <<<<<< new code
       // *sig = SIGTRAP;             <<<<<< existing code
       // err = func;                 <<<<<< existing code
   } else {
       CYGACC_CALL_IF_MONITOR_RETURN(arg1);
       // never returns
   }
   break;
      ...      
===========================================================
I assume (but am not sure) that eCos programs should not be concerned by
such a change since the eCos implementation of exit() does not trigger a
RedBoot syscall (?).

Does such a modification to the exit syscall make sense ?
Is it acceptable for any eCos (either redboot only or kernel based)
application ?

Thanks in advance for any feedback.

Pierre
-- 
________________________________________________________________________
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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Mark Salter]

>>>>> Pierre Habraken writes:

> Hello,
> I have a question about the way the exit() libc function is dealt with:

> With Angel, the native on board debug monitor shipped with the E7T, when
> a program calls exit(0) then the control is smoothly given back to gdb:
> ===========================================================
> (gdb) continue
> ...
> Program exited normally.
> (gdb)
> ===========================================================

> With the current version of RedBoot, control is given back to gdb by
> raising a SIGTRAP signal:
> ===========================================================
> (gdb) continue
> ...
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x000101bc in _exit (stat=8)
>     at ../../../../../newlib-1.11.0/libgloss/arm/redboot-syscalls.c:54
> 54              __syscall(SYS_exit, stat);
> (gdb)
> ===========================================================

> These boards together with RedBoot are (will be) used by undergraduate
> unexperimented students. The above message displayed by gdb at the end
> of program execution is of no use for them and may confuse most of them.
> So, I'd like to get gdb+redboot have the same external behavior as
> gdb+angel, as far as possible.
> I did some investigations and tests that let me think that this goal
> could be achieved by applying the modification below to

The trap in exit was a conscious decision. Any patch to change this
behavior will need to be configurable.

> I assume (but am not sure) that eCos programs should not be concerned by
> such a change since the eCos implementation of exit() does not trigger a
> RedBoot syscall (?).

Right. Only newlib/libgloss based apps use those syscalls.

> Does such a modification to the exit syscall make sense ?

It makes sense, but reasonable arguments can be made for the current
behavior as well.

> Is it acceptable for any eCos (either redboot only or kernel based)
> application ?

Something to watch out for is that any patch not break the ability to
quit GDB and return to the RedBoot prompt. Also, I think changing the
current behavior will cause a problem with running the GDB testsuites
on RedBoot enabled boards.

--Mark

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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Pierre Habraken]

Mark Salter wrote:
> [...]
> Something to watch out for is that any patch not break the ability to
> quit GDB and return to the RedBoot prompt.

Aaaarg... the RedBoot prompt is lost ! : it replies to any key stroke by
sending a SIGTRAP message: $T050f:242d8201;0d:448f0000;#5a.

I must admit that my understanding of the RedBoot main loop operation is
very light and indeed I was surprised that such a simplistic change
could achieve what I was trying to do !

I was fooled by the fact that gdb could re-connect to RedBoot and load
again the test program right after having quit ; it could even re-load
the program right after having displayed the message 'Program exited
normally.'. So, I did not think of checking that point...

BTW, I do not understand how gdb can make RedBoot willing to talk with
where it refuses to do it with myself using a comm. program...

Pierre

PS: I'd like to be able to step by step in RedBoot in order to
understand better how it operates, but up to now I failed to run it as a
RAM image: I built it using cdl options CYGSEM_HAL_ROM_MONITOR
(inferred_value 1) and CYG_HAL_STARTUP (user_value ROM) and load it at
address 0x10000, but it does not want to start (using E7T BSL command
'go'). Any idea someone ?...
-- 
________________________________________________________________________
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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Jonathan Larmour]

Pierre Habraken wrote:
> Mark Salter wrote:
> 
>>[...]
>>Something to watch out for is that any patch not break the ability to
>>quit GDB and return to the RedBoot prompt.

Haven't tried it so I'm probably way off base, but could this maybe simply 
be done by making the code in question just be:

        __send_exit_status((int)arg1);
        CYGACC_CALL_IF_MONITOR_RETURN(arg1);

> PS: I'd like to be able to step by step in RedBoot in order to
> understand better how it operates, but up to now I failed to run it as a
> RAM image: I built it using cdl options CYGSEM_HAL_ROM_MONITOR
> (inferred_value 1) and CYG_HAL_STARTUP (user_value ROM) and load it at
> address 0x10000, but it does not want to start (using E7T BSL command
> 'go'). Any idea someone ?...

If those options are set for a ROM it will want to have been loaded in 
ROM. To build for RAM you have to disable CYGSEM_HAL_ROM_MONITOR and set 
CYG_HAL_STARTUP to RAM, not very surprisingly really! Only the latter is 
required in fact as CYGSEM_HAL_ROM_MONITOR should set itself accordingly.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Mark Salter]

>>>>> Jonathan Larmour writes:

> Pierre Habraken wrote:
>> Mark Salter wrote:
>> 
>>> [...]
>>> Something to watch out for is that any patch not break the ability to
>>> quit GDB and return to the RedBoot prompt.

> Haven't tried it so I'm probably way off base, but could this maybe simply 
> be done by making the code in question just be:

>         __send_exit_status((int)arg1);
>         CYGACC_CALL_IF_MONITOR_RETURN(arg1);

This isn't way off base, but it won't work right now. The context used by
CYGACC_CALL_IF_MONITOR_RETURN is only setup through the 'go' command right
now. The return back to stub is handled by saving a context on the first
entry to the stub and then restoring that context when a 'k' packet is
received from GDB. We could get rid of that mechanism (good riddance) and
setup a context for CYGACC_CALL_IF_MONITOR_RETURN before entering the stub.

--Mark

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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Pierre Habraken]

Jonathan Larmour wrote:
> 
> > PS: I'd like to be able to step by step in RedBoot in order to
> > understand better how it operates, but up to now I failed to run
> > it as a RAM image: I built it using cdl options
> > CYGSEM_HAL_ROM_MONITOR (inferred_value 1) and CYG_HAL_STARTUP
> > (user_value ROM) and load it at address 0x10000, but it does not
> > want to start (using E7T BSL command 'go'). Any idea someone ?...
> 
> If those options are set for a ROM it will want to have been loaded in
> ROM. To build for RAM you have to disable CYGSEM_HAL_ROM_MONITOR and
> set CYG_HAL_STARTUP to RAM, not very surprisingly really!
> Only the latter is required in fact as CYGSEM_HAL_ROM_MONITOR should
> set itself accordingly.

Sorry, it's a copy/paste mistake : I pasted in my message the contents
of the redboot_ROM.ecm file though I actually rebuilt RedBoot using a
modified file (redboot_RAM.ecm) with option CYG_HAL_STARTUP set to RAM
(unless I made the same kind of mistake when importing the .ecm file)...
I'll make a new trial.

Pierre
-- 
________________________________________________________________________
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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Jonathan Larmour]

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

Just to avoid any doubt, Pierre, are you going to look at this? You're the 
one with the incentive to do it :-). Look at the various places that 
go_saved_context is used in redboot's src/main.c.

I think the attached patch might do it, but it's purely off the top of my 
head. If it does then all you need to do to finish it off is just rename 
go_saved_context to redboot_return_context or something like that, and 
something similar for go_trampoline; and then most importantly test it 
with the below exit status change as well to verify it all builds and 
works. Oh, and add ChangeLog entries :).

Jifl

Mark Salter wrote:
>>>>>>Jonathan Larmour writes:
> 
> 
>>Pierre Habraken wrote:
>>
>>>Mark Salter wrote:
>>>
>>>
>>>>[...]
>>>>Something to watch out for is that any patch not break the ability to
>>>>quit GDB and return to the RedBoot prompt.
> 
> 
>>Haven't tried it so I'm probably way off base, but could this maybe simply 
>>be done by making the code in question just be:
> 
> 
>>        __send_exit_status((int)arg1);
>>        CYGACC_CALL_IF_MONITOR_RETURN(arg1);
> 
> 
> This isn't way off base, but it won't work right now. The context used by
> CYGACC_CALL_IF_MONITOR_RETURN is only setup through the 'go' command right
> now. The return back to stub is handled by saving a context on the first
> entry to the stub and then restoring that context when a 'k' packet is
> received from GDB. We could get rid of that mechanism (good riddance) and
> setup a context for CYGACC_CALL_IF_MONITOR_RETURN before entering the stub.
> 
> --Mark
> 


-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

[-- Attachment #2: redboot.contextswap.pat --]
[-- Type: text/plain, Size: 1473 bytes --]

? src/flash.c.at91flash.dead
Index: src/main.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/redboot/current/src/main.c,v
retrieving revision 1.44
diff -u -5 -p -r1.44 main.c
--- src/main.c	8 Apr 2003 05:09:06 -0000	1.44
+++ src/main.c	24 Apr 2003 02:24:53 -0000
@@ -314,14 +314,20 @@ cyg_start(void)
                     __chan = CYGACC_CALL_IF_CONSOLE_PROCS();
                     CYGACC_COMM_IF_CONTROL( *__chan, __COMMCTL_IRQ_DISABLE );
                 }
     
                 CYGACC_CALL_IF_SET_CONSOLE_COMM(cur);
+                // set up a temporary context that will take us to the trampoline
+                HAL_THREAD_INIT_CONTEXT((CYG_ADDRESS)workspace_end, &breakpoint, go_trampoline, 0);
+
+                // switch context to trampoline
+                HAL_THREAD_SWITCH_CONTEXT(&go_saved_context, &workspace_end);
+
 #ifdef HAL_ARCH_PROGRAM_NEW_STACK
-                HAL_ARCH_PROGRAM_NEW_STACK(breakpoint);
+                //                HAL_ARCH_PROGRAM_NEW_STACK(breakpoint);
 #else
-                breakpoint();  // Get GDB stubs started, with a proper environment, etc.
+                //                breakpoint();  // Get GDB stubs started, with a proper environment, etc.
 #endif
 		dbgchan = CYGACC_CALL_IF_SET_DEBUG_COMM(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT);
 		CYGACC_CALL_IF_SET_CONSOLE_COMM(dbgchan);
             } else 
 #endif // CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS


[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Pierre Habraken]

Jonathan Larmour wrote:
> 
> Just to avoid any doubt, Pierre, are you going to look at this?
> You're the one with the incentive to do it :-).

Sure, I'm going to look at it ! I just can't promise when I'll do it:
I am just a full time teacher, not a developer, not even a researcher,
and have very few time only left for working on development/debugging
tasks...


> Look at the various places that
> go_saved_context is used in redboot's src/main.c.
> 
> I think the attached patch might do it, but it's purely off the top
> of my head. If it does then all you need to do to finish it off is
> just rename go_saved_context to redboot_return_context or something
> like that, and something similar for go_trampoline; and then most
> importantly test it with the below exit status change as well to
> verify it all builds and works. Oh, and add ChangeLog entries :).

OK. I still have to understand all this stuff (not really easy to follow
all these macro-defined functions with concatenated names operating on
indirection table(s) !)... I'll apply and test your patch as soon as
possible and let you know the results.

Pierre

PS: I assume that the main argument for sending a SIGTRAP when an app
terminates is that it provides the developer with a way to back trace to
the location in his/her source code where exit() was called. Besides
that, do you see any other argument in favor of this behavior ?


> Mark Salter wrote:
> >>>>>>Jonathan Larmour writes:
> >
> >
> >>Pierre Habraken wrote:
> >>
> >>>Mark Salter wrote:
> >>>
> >>>
> >>>>[...]
> >>>>Something to watch out for is that any patch not break the ability to
> >>>>quit GDB and return to the RedBoot prompt.
> >
> >
> >>Haven't tried it so I'm probably way off base, but could this maybe simply
> >>be done by making the code in question just be:
> >
> >
> >>        __send_exit_status((int)arg1);
> >>        CYGACC_CALL_IF_MONITOR_RETURN(arg1);
> >
> >
> > This isn't way off base, but it won't work right now. The context used by
> > CYGACC_CALL_IF_MONITOR_RETURN is only setup through the 'go' command right
> > now. The return back to stub is handled by saving a context on the first
> > entry to the stub and then restoring that context when a 'k' packet is
> > received from GDB. We could get rid of that mechanism (good riddance) and
> > setup a context for CYGACC_CALL_IF_MONITOR_RETURN before entering the stub.
> >
> > --Mark
> >
> 
> --
> eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
> 
>   ------------------------------------------------------------------------
> ? src/flash.c.at91flash.dead
> Index: src/main.c
> ===================================================================
> RCS file: /cvs/ecos/ecos/packages/redboot/current/src/main.c,v
> retrieving revision 1.44
> diff -u -5 -p -r1.44 main.c
> --- src/main.c  8 Apr 2003 05:09:06 -0000       1.44
> +++ src/main.c  24 Apr 2003 02:24:53 -0000
> @@ -314,14 +314,20 @@ cyg_start(void)
>                      __chan = CYGACC_CALL_IF_CONSOLE_PROCS();
>                      CYGACC_COMM_IF_CONTROL( *__chan, __COMMCTL_IRQ_DISABLE );
>                  }
> 
>                  CYGACC_CALL_IF_SET_CONSOLE_COMM(cur);
> +                // set up a temporary context that will take us to the trampoline
> +                HAL_THREAD_INIT_CONTEXT((CYG_ADDRESS)workspace_end, &breakpoint, go_trampoline, 0);
> +
> +                // switch context to trampoline
> +                HAL_THREAD_SWITCH_CONTEXT(&go_saved_context, &workspace_end);
> +
>  #ifdef HAL_ARCH_PROGRAM_NEW_STACK
> -                HAL_ARCH_PROGRAM_NEW_STACK(breakpoint);
> +                //                HAL_ARCH_PROGRAM_NEW_STACK(breakpoint);
>  #else
> -                breakpoint();  // Get GDB stubs started, with a proper environment, etc.
> +                //                breakpoint();  // Get GDB stubs started, with a proper environment, etc.
>  #endif
>                 dbgchan = CYGACC_CALL_IF_SET_DEBUG_COMM(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT);
>                 CYGACC_CALL_IF_SET_CONSOLE_COMM(dbgchan);
>              } else
>  #endif // CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS

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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Mark Salter]

>>>>> Mark Salter writes:

>>>>> Jonathan Larmour writes:
>> Pierre Habraken wrote:
>>> Mark Salter wrote:
>>> 
>>>> [...]
>>>> Something to watch out for is that any patch not break the ability to
>>>> quit GDB and return to the RedBoot prompt.

>> Haven't tried it so I'm probably way off base, but could this maybe simply 
>> be done by making the code in question just be:

>> __send_exit_status((int)arg1);
>> CYGACC_CALL_IF_MONITOR_RETURN(arg1);

> This isn't way off base, but it won't work right now. The context used by
> CYGACC_CALL_IF_MONITOR_RETURN is only setup through the 'go' command right
> now. The return back to stub is handled by saving a context on the first
> entry to the stub and then restoring that context when a 'k' packet is
> received from GDB. We could get rid of that mechanism (good riddance) and
> setup a context for CYGACC_CALL_IF_MONITOR_RETURN before entering the stub.

I'm having some doubts about this. I wonder if it is really portable
to do things this way. The HAL_THREAD_* macros are designed to work
from a task context. I think there could be problems with using them
in an exception/interrupt context on some architectures. Specifically,
those architectures that have special "return from exception" insns
which have side effects that the HAL_THREAD_* macros don't duplicate.

--Mark




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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Pierre Habraken]

Jonathan Larmour wrote:
> 
> Just to avoid any doubt, Pierre, are you going to look at this?
> You're the one with the incentive to do it :-).
> Look at the various places that go_saved_context is used in
> redboot's src/main.c.
> 
> I think the attached patch might do it, but it's purely off the
> top of my head. If it does then all you need to do to finish it
> off is just rename go_saved_context to redboot_return_context or
> something like that, and something similar for go_trampoline;
> and then most importantly test it with the below exit status change
> as well to verify it all builds and works. Oh, and add ChangeLog
> entries :).

I'm back after I have been busy for some time with some other matters.
So, I just applied your patch to main.c (together with the change in
syscall.c): it produces the expected behavior.
However, I have not understood why you said I had to rename
'go_saved_context' and 'go_trampoline': I just added some early
declaration for both features at the beginning of the file and then
everything built and ran fine. But I probably missed something. Could
you please clarify that point ?

In accordance with Mark's previous warning I checked that this time
quitting gdb makes RedBoot return to its main prompt.
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 ?

Besides that I also created a cdl option named
CYGOPT_REDBOOT_BSP_SYSCALLS_EXIT_WITHOUT_TRAP so that this new feature
be enabled in syscall.c when it is desirable only.

I am waiting for confirmation from both of you, Jonathan and Mark, and
then I'll send a full patch with ChangeLog entry.

Pierre


> Mark Salter wrote:
> >>>>>>Jonathan Larmour writes:
> >
> >
> >>Pierre Habraken wrote:
> >>
> >>>Mark Salter wrote:
> >>>
> >>>
> >>>>[...]
> >>>>Something to watch out for is that any patch not break the ability to
> >>>>quit GDB and return to the RedBoot prompt.
> >
> >
> >>Haven't tried it so I'm probably way off base, but could this maybe simply
> >>be done by making the code in question just be:
> >
> >
> >>        __send_exit_status((int)arg1);
> >>        CYGACC_CALL_IF_MONITOR_RETURN(arg1);
> >
> >
> > This isn't way off base, but it won't work right now. The context used by
> > CYGACC_CALL_IF_MONITOR_RETURN is only setup through the 'go' command right
> > now. The return back to stub is handled by saving a context on the first
> > entry to the stub and then restoring that context when a 'k' packet is
> > received from GDB. We could get rid of that mechanism (good riddance) and
> > setup a context for CYGACC_CALL_IF_MONITOR_RETURN before entering the stub.
> >
> > --Mark
> >
> 
> --
> eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
> 
>   ------------------------------------------------------------------------
> ? src/flash.c.at91flash.dead
> Index: src/main.c
> ===================================================================
> RCS file: /cvs/ecos/ecos/packages/redboot/current/src/main.c,v
> retrieving revision 1.44
> diff -u -5 -p -r1.44 main.c
> --- src/main.c  8 Apr 2003 05:09:06 -0000       1.44
> +++ src/main.c  24 Apr 2003 02:24:53 -0000
> @@ -314,14 +314,20 @@ cyg_start(void)
>                      __chan = CYGACC_CALL_IF_CONSOLE_PROCS();
>                      CYGACC_COMM_IF_CONTROL( *__chan, __COMMCTL_IRQ_DISABLE );
>                  }
> 
>                  CYGACC_CALL_IF_SET_CONSOLE_COMM(cur);
> +                // set up a temporary context that will take us to the trampoline
> +                HAL_THREAD_INIT_CONTEXT((CYG_ADDRESS)workspace_end, &breakpoint, go_trampoline, 0);
> +
> +                // switch context to trampoline
> +                HAL_THREAD_SWITCH_CONTEXT(&go_saved_context, &workspace_end);
> +
>  #ifdef HAL_ARCH_PROGRAM_NEW_STACK
> -                HAL_ARCH_PROGRAM_NEW_STACK(breakpoint);
> +                //                HAL_ARCH_PROGRAM_NEW_STACK(breakpoint);
>  #else
> -                breakpoint();  // Get GDB stubs started, with a proper environment, etc.
> +                //                breakpoint();  // Get GDB stubs started, with a proper environment, etc.
>  #endif
>                 dbgchan = CYGACC_CALL_IF_SET_DEBUG_COMM(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT);
>                 CYGACC_CALL_IF_SET_CONSOLE_COMM(dbgchan);
>              } else
>  #endif // CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS

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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Mark Salter]

>>>>> Pierre Habraken writes:

> In accordance with Mark's previous warning I checked that this time
> quitting gdb makes RedBoot return to its main prompt.
> 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.

--Mark

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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Pierre Habraken]

Pierre Habraken wrote:
> [...]
> However, I have not understood why you said I had to rename
> 'go_saved_context' and 'go_trampoline': I just added some early
> declaration for both features at the beginning of the file and then
> everything built and ran fine. But I probably missed something. Could
> you please clarify that point ?

Forget that stupid question !...

Pierre
-- 
________________________________________________________________________
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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Pierre Habraken]

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

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

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 ?

Pierre
-- 
________________________________________________________________________
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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Mark Salter]

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

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

Re: [ECOS] Calling exit in a Redboot standalone Arm program

[Pierre Habraken]

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