[ECOS] how work synthetic for exceptions

[ECOS] how work synthetic for exceptions

[trollepi jj]

Hi,
I try do modify the execution of a thread for the synthetic target.
I've done that for an at91 board (using SWI,exception hanler and HAL_SavedRegisters to store the context info).
I put an exception handler for the CYG_HAL_SYS_SIGILL to see if i get the info pointers of the handler (3rd parameter of the function).
I reach the exception handler and have this backtrace call from gdb


#0  simple_syscall_handler (data=2, number=0, info=0) at main.c:56
#1  0x01004c7c in Cyg_Exception_Control::deliver_exception (this=0x2004560, exception_number=0, 
    exception_info=0) at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:235
#2  0x010042bf in Cyg_Thread::deliver_exception (this=0x20004c0, exception_number=0, exception_info=0)
    at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1013
#3  0x01004ce0 in cyg_hal_deliver_exception (code=0, data=0)
    at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:248
#4  0x0100160d in synth_exception_sighandler (sig=4)
    at /home/pitrolle/ecos/ecos/packages/hal/synth/arch/current/src/synth_intr.c:460
#5  0x01002e18 in cyg_hal_sys_restore_rt ()
    at /home/pitrolle/ecos/ecos/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S:446
#6  0x00000004 in ?? ()
#7  0x0100418c in idle_thread_main (data=0)
    at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1231
#8  0x01004be0 in Cyg_HardwareThread::thread_entry (thread=0x20004c0)
    at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:95
#9  0x00000000 in ?? ()

I have severals questions :
 - What is the real aim of cyg_hal_sys_restore_rt?
 - If I want to get the context of the thread on the exception handler (info about saved registers like previous pc,sp,...) , what can i process?

Thank for future help, Best Regars
jjp
_________________________________________________________________
Lancez des recherches en toute sécurité depuis n'importe quelle page Web. Téléchargez GRATUITEMENT Windows Live Toolbar aujourd'hui !
http://toolbar.live.com

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

Re: [ECOS] how work synthetic for exceptions

[Gary Thomas]

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

trollepi jj wrote:
> Hi,
> I try do modify the execution of a thread for the synthetic target.
> I've done that for an at91 board (using SWI,exception hanler and HAL_SavedRegisters to store the context info).
> I put an exception handler for the CYG_HAL_SYS_SIGILL to see if i get the info pointers of the handler (3rd parameter of the function).
> I reach the exception handler and have this backtrace call from gdb
> 
> 
> #0  simple_syscall_handler (data=2, number=0, info=0) at main.c:56
> #1  0x01004c7c in Cyg_Exception_Control::deliver_exception (this=0x2004560, exception_number=0, 
>     exception_info=0) at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:235
> #2  0x010042bf in Cyg_Thread::deliver_exception (this=0x20004c0, exception_number=0, exception_info=0)
>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1013
> #3  0x01004ce0 in cyg_hal_deliver_exception (code=0, data=0)
>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:248
> #4  0x0100160d in synth_exception_sighandler (sig=4)
>     at /home/pitrolle/ecos/ecos/packages/hal/synth/arch/current/src/synth_intr.c:460
> #5  0x01002e18 in cyg_hal_sys_restore_rt ()
>     at /home/pitrolle/ecos/ecos/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S:446
> #6  0x00000004 in ?? ()
> #7  0x0100418c in idle_thread_main (data=0)
>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1231
> #8  0x01004be0 in Cyg_HardwareThread::thread_entry (thread=0x20004c0)
>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:95
> #9  0x00000000 in ?? ()
> 
> I have severals questions :
>  - What is the real aim of cyg_hal_sys_restore_rt?
>  - If I want to get the context of the thread on the exception handler (info about saved registers like previous pc,sp,...) , what can i process?

Note: if you're trying to use the SWI exception, then I think
you need to apply the attached patch (I've not had a chance to
try it as I don't have access to ARM hardware).

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 615 bytes --]

Index: hal/arm/arch/current/src/vectors.S
===================================================================
--- hal/arm/arch/current/src/vectors.S	(revision 3391)
+++ hal/arm/arch/current/src/vectors.S	(working copy)
@@ -539,7 +539,8 @@
         tst     r1,#CPSR_THUMB_ENABLE
         subeq   r0,lr,#4                // PC at time of SWI (ARM)
         subne   r0,lr,#2                // PC at time of SWI (thumb)
-        mov     r2,#CYGNUM_HAL_EXCEPTION_INTERRUPT
+        mov     r2,#CYGNUM_HAL_EXCEPTION_SOFTWARE_INTERRUPT
+        mov     r3,sp
         b       call_exception_handler
 
         .code   32


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

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

RE: [ECOS] how work synthetic for exceptions

[trollepi jj]

Hi,
the SWI mecanism work well. (with a RAM config, the path and other modifications)
I just want to experiment the same thing on the synthetic target for the advantages that you know. (In this case replace the SWI by signal mecanism)
Best regards.
jjp
----------------------------------------
> Date: Thu, 3 Apr 2008 06:25:55 -0600
> From: gary@mlbassoc.com
> To: jackoaway@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] how work synthetic for exceptions
> 
> trollepi jj wrote:
>> Hi,
>> I try do modify the execution of a thread for the synthetic target.
>> I've done that for an at91 board (using SWI,exception hanler and HAL_SavedRegisters to store the context info).
>> I put an exception handler for the CYG_HAL_SYS_SIGILL to see if i get the info pointers of the handler (3rd parameter of the function).
>> I reach the exception handler and have this backtrace call from gdb
>> 
>> 
>> #0  simple_syscall_handler (data=2, number=0, info=0) at main.c:56
>> #1  0x01004c7c in Cyg_Exception_Control::deliver_exception (this=0x2004560, exception_number=0, 
>>     exception_info=0) at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:235
>> #2  0x010042bf in Cyg_Thread::deliver_exception (this=0x20004c0, exception_number=0, exception_info=0)
>>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1013
>> #3  0x01004ce0 in cyg_hal_deliver_exception (code=0, data=0)
>>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:248
>> #4  0x0100160d in synth_exception_sighandler (sig=4)
>>     at /home/pitrolle/ecos/ecos/packages/hal/synth/arch/current/src/synth_intr.c:460
>> #5  0x01002e18 in cyg_hal_sys_restore_rt ()
>>     at /home/pitrolle/ecos/ecos/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S:446
>> #6  0x00000004 in ?? ()
>> #7  0x0100418c in idle_thread_main (data=0)
>>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1231
>> #8  0x01004be0 in Cyg_HardwareThread::thread_entry (thread=0x20004c0)
>>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:95
>> #9  0x00000000 in ?? ()
>> 
>> I have severals questions :
>>  - What is the real aim of cyg_hal_sys_restore_rt?
>>  - If I want to get the context of the thread on the exception handler (info about saved registers like previous pc,sp,...) , what can i process?
> 
> Note: if you're trying to use the SWI exception, then I think
> you need to apply the attached patch (I've not had a chance to
> try it as I don't have access to ARM hardware).
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------

_________________________________________________________________
Lancez des recherches en toute sécurité depuis n'importe quelle page Web. Téléchargez GRATUITEMENT Windows Live Toolbar aujourd'hui !
http://toolbar.live.com

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

Re: [ECOS] how work synthetic for exceptions

[Andrew Lunn]

On Thu, Apr 03, 2008 at 01:01:11PM +0100, trollepi jj wrote:
> 
> Hi,
> I try do modify the execution of a thread for the synthetic target.
> I've done that for an at91 board (using SWI,exception hanler and HAL_SavedRegisters to store the context info).
> I put an exception handler for the CYG_HAL_SYS_SIGILL to see if i get the info pointers of the handler (3rd parameter of the function).

A normal signal handler does not have access to the registers for the
normal program flow when the signal went off. However, there is often
an undocumented way to get access to this. Take a look at:

http://www.tlug.org.za/wiki/index.php/Obtaining_a_stack_trace_in_C_upon_SIGSEGV

Using this it might be able to generate a HAL_SavedRegisters set.

      Andrew

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

RE: [ECOS] how work synthetic for exceptions

[trollepi jj]

Thanks for your quick reply.
I take a look on your link.
jjp
----------------------------------------
> Date: Thu, 3 Apr 2008 14:48:03 +0200
> From: andrew@lunn.ch
> To: jackoaway@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] how work synthetic for exceptions
> 
> On Thu, Apr 03, 2008 at 01:01:11PM +0100, trollepi jj wrote:
>> 
>> Hi,
>> I try do modify the execution of a thread for the synthetic target.
>> I've done that for an at91 board (using SWI,exception hanler and HAL_SavedRegisters to store the context info).
>> I put an exception handler for the CYG_HAL_SYS_SIGILL to see if i get the info pointers of the handler (3rd parameter of the function).
> 
> A normal signal handler does not have access to the registers for the
> normal program flow when the signal went off. However, there is often
> an undocumented way to get access to this. Take a look at:
> 
> http://www.tlug.org.za/wiki/index.php/Obtaining_a_stack_trace_in_C_upon_SIGSEGV
> 
> Using this it might be able to generate a HAL_SavedRegisters set.
> 
>       Andrew

_________________________________________________________________
Lancez des recherches en toute sécurité depuis n'importe quelle page Web. Téléchargez GRATUITEMENT Windows Live Toolbar aujourd'hui !
http://toolbar.live.com

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

Re: [ECOS] how work synthetic for exceptions

[Andrew Lunn]

On Wed, Apr 09, 2008 at 09:19:57AM +0100, trollepi jj wrote:
> 
> Hi,
> We have successfully implement the same mecanism (a kind of softirq) on the synthetic target. We modify and add some structures to meet the requirements of linux signal implementation.
> But we have a conception question :
> Why do you coding the call of the syscall in the file syscall-i386-linux-1.0.S? Is it impossible for the synthetic to call directly a syscall (confusion between gnu/linux libC and eCos lib, stack issues)?

Correct. eCos does not link with the native libc, it directly calls
kernel system calls. There is no way to tell the linker that a call to
read() in file X.c should call the native glibc read() function, but a
call to read() in Y.c should call the eCos libc read function.

     Andrew

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

RE: [ECOS] how work synthetic for exceptions

[trollepi jj]

Hi,
We have successfully implement the same mecanism (a kind of softirq) on the synthetic target. We modify and add some structures to meet the requirements of linux signal implementation.
But we have a conception question :
Why do you coding the call of the syscall in the file syscall-i386-linux-1.0.S? Is it impossible for the synthetic to call directly a syscall (confusion between gnu/linux libC and eCos lib, stack issues)?
Best regards
----------------------------------------
> Date: Thu, 3 Apr 2008 14:23:53 +0100
> From: bartv@ecoscentric.com
> To: jackoaway@hotmail.com
> CC: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] how work synthetic for exceptions
> 
>>>>>> "jjp" == trollepi jj  writes:
> 
>     jjp> Hi,
>     jjp> I try do modify the execution of a thread for the synthetic
>     jjp> target. I've done that for an at91 board (using SWI,exception
>     jjp> hanler and HAL_SavedRegisters to store the context info). I
>     jjp> put an exception handler for the CYG_HAL_SYS_SIGILL to see if
>     jjp> i get the info pointers of the handler (3rd parameter of the
>     jjp> function). I reach the exception handler and have this
>     jjp> backtrace call from gdb
> 
>     jjp> #0  simple_syscall_handler (data=2, number=0, info=0) at main.c:56
>     jjp> #1  0x01004c7c in Cyg_Exception_Control::deliver_exception (this=0x2004560, exception_number=0, 
>     jjp>     exception_info=0) at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:235
>     jjp> #2  0x010042bf in Cyg_Thread::deliver_exception (this=0x20004c0, exception_number=0, exception_info=0)
>     jjp>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1013
>     jjp> #3  0x01004ce0 in cyg_hal_deliver_exception (code=0, data=0)
>     jjp>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:248
>     jjp> #4  0x0100160d in synth_exception_sighandler (sig=4)
>     jjp>     at /home/pitrolle/ecos/ecos/packages/hal/synth/arch/current/src/synth_intr.c:460
>     jjp> #5  0x01002e18 in cyg_hal_sys_restore_rt ()
>     jjp>     at /home/pitrolle/ecos/ecos/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S:446
>     jjp> #6  0x00000004 in ?? ()
>     jjp> #7  0x0100418c in idle_thread_main (data=0)
>     jjp>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1231
>     jjp> #8  0x01004be0 in Cyg_HardwareThread::thread_entry (thread=0x20004c0)
>     jjp>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:95
>     jjp> #9  0x00000000 in ?? ()
> 
>     jjp> I have severals questions :
>     jjp>  - What is the real aim of cyg_hal_sys_restore_rt?
> 
> From the source code (syscall-i386-linux-1.0.S):
> 
> // ----------------------------------------------------------------------------
> // Special support for returning from a signal handler. In theory no special
> // action is needed, but with some versions of the kernel on some
> // architectures that is not good enough. Instead returning has to happen
> // via another system call.         
> 
>         .align 16
>         .global cyg_hal_sys_restore_rt
>         ...
> 
> The exact details of low-level signal handling on x86 get very messy.
> Generally it is best not to worry too much about the details.
> 	
>     jjp>  - If I want to get the context of the thread on the
>     jjp>  exception handler (info about saved registers like previous
>     jjp>  pc,sp,...) , what can i process?
> 
> Currently the synthetic target HAL does not collect this information -
> it is not required for a basic implementation of the HAL
> specification. What you would probably need to do is modify the
> architectural HAL's synth_intr.c so that when it installs
> synth_exception_sighandler() with sigaction() it uses the
> CYG_HAL_SYS_SA_SIGINFO flag (man sigaction for details). Then change
> the exception handler to accept two additional arguments, a
> cyg_hal_sys_siginfo_t and a cyg_hal_sys_ucontext_t. Both of these
> structures will need to be defined somewhere, with ucontext_t
> probably going into the i386linux HAL. Then you still have to figure
> out what to do with the extra information.
> 
> Note that you can probably do most/all of this in your application if
> desired, if you wish to avoid modifying the eCos HAL packages. During
> startup your application can use cyg_hal_sys_sigaction() to install
> replacement exception handlers.
> 
> Bart
> 
> -- 
> Bart Veer                                   eCos Configuration Architect
> eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
> Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
> Registered in England and Wales: Reg No 4422071.
>   **  Visit us at ESC Silicon Valley   **
>   **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 

_________________________________________________________________
Téléchargez le nouveau Windows Live Messenger !
http://get.live.com/messenger/overview

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

Re: [ECOS] how work synthetic for exceptions

[Bart Veer]

>>>>> "jjp" == trollepi jj <jackoaway@hotmail.com> writes:

    jjp> Hi,
    jjp> I try do modify the execution of a thread for the synthetic
    jjp> target. I've done that for an at91 board (using SWI,exception
    jjp> hanler and HAL_SavedRegisters to store the context info). I
    jjp> put an exception handler for the CYG_HAL_SYS_SIGILL to see if
    jjp> i get the info pointers of the handler (3rd parameter of the
    jjp> function). I reach the exception handler and have this
    jjp> backtrace call from gdb

    jjp> #0  simple_syscall_handler (data=2, number=0, info=0) at main.c:56
    jjp> #1  0x01004c7c in Cyg_Exception_Control::deliver_exception (this=0x2004560, exception_number=0, 
    jjp>     exception_info=0) at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:235
    jjp> #2  0x010042bf in Cyg_Thread::deliver_exception (this=0x20004c0, exception_number=0, exception_info=0)
    jjp>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1013
    jjp> #3  0x01004ce0 in cyg_hal_deliver_exception (code=0, data=0)
    jjp>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:248
    jjp> #4  0x0100160d in synth_exception_sighandler (sig=4)
    jjp>     at /home/pitrolle/ecos/ecos/packages/hal/synth/arch/current/src/synth_intr.c:460
    jjp> #5  0x01002e18 in cyg_hal_sys_restore_rt ()
    jjp>     at /home/pitrolle/ecos/ecos/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S:446
    jjp> #6  0x00000004 in ?? ()
    jjp> #7  0x0100418c in idle_thread_main (data=0)
    jjp>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1231
    jjp> #8  0x01004be0 in Cyg_HardwareThread::thread_entry (thread=0x20004c0)
    jjp>     at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:95
    jjp> #9  0x00000000 in ?? ()

    jjp> I have severals questions :
    jjp>  - What is the real aim of cyg_hal_sys_restore_rt?

From the source code (syscall-i386-linux-1.0.S):

// ----------------------------------------------------------------------------
// Special support for returning from a signal handler. In theory no special
// action is needed, but with some versions of the kernel on some
// architectures that is not good enough. Instead returning has to happen
// via another system call.         

        .align 16
        .global cyg_hal_sys_restore_rt
        ...

The exact details of low-level signal handling on x86 get very messy.
Generally it is best not to worry too much about the details.
	
    jjp>  - If I want to get the context of the thread on the
    jjp>  exception handler (info about saved registers like previous
    jjp>  pc,sp,...) , what can i process?

Currently the synthetic target HAL does not collect this information -
it is not required for a basic implementation of the HAL
specification. What you would probably need to do is modify the
architectural HAL's synth_intr.c so that when it installs
synth_exception_sighandler() with sigaction() it uses the
CYG_HAL_SYS_SA_SIGINFO flag (man sigaction for details). Then change
the exception handler to accept two additional arguments, a
cyg_hal_sys_siginfo_t and a cyg_hal_sys_ucontext_t. Both of these
structures will need to be defined somewhere, with ucontext_t
probably going into the i386linux HAL. Then you still have to figure
out what to do with the extra information.

Note that you can probably do most/all of this in your application if
desired, if you wish to avoid modifying the eCos HAL packages. During
startup your application can use cyg_hal_sys_sigaction() to install
replacement exception handlers.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
  **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
  **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **

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

[ECOS] how work synthetic for exceptions

[trollepi jj]

Hi,
I try do modify the execution of a thread for the synthetic target.
I've done that for an at91 board (using SWI,exception hanler and HAL_SavedRegisters to store the context info).
I put an exception handler for the CYG_HAL_SYS_SIGILL to see if i get the info pointers of the handler (3rd parameter of the function).
I reach the exception handler and have this backtrace call from gdb


#0  simple_syscall_handler (data=2, number=0, info=0) at main.c:56
#1  0x01004c7c in Cyg_Exception_Control::deliver_exception (this=0x2004560, exception_number=0, 
    exception_info=0) at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:235
#2  0x010042bf in Cyg_Thread::deliver_exception (this=0x20004c0, exception_number=0, exception_info=0)
    at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1013
#3  0x01004ce0 in cyg_hal_deliver_exception (code=0, data=0)
    at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/except.cxx:248
#4  0x0100160d in synth_exception_sighandler (sig=4)
    at /home/pitrolle/ecos/ecos/packages/hal/synth/arch/current/src/synth_intr.c:460
#5  0x01002e18 in cyg_hal_sys_restore_rt ()
    at /home/pitrolle/ecos/ecos/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S:446
#6  0x00000004 in ?? ()
#7  0x0100418c in idle_thread_main (data=0)
    at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:1231
#8  0x01004be0 in Cyg_HardwareThread::thread_entry (thread=0x20004c0)
    at /home/pitrolle/ecos/ecos/packages/kernel/current/src/common/thread.cxx:95
#9  0x00000000 in ?? ()

I have severals questions :
 - What is the real aim of cyg_hal_sys_restore_rt?
 - If I want to get the context of the thread on the exception handler (info about saved registers like previous pc,sp,...) , what can i process?

Thank for future help, Best Regars
jjp
_________________________________________________________________
Lancez des recherches en toute sécurité depuis n'importe quelle page Web. Téléchargez GRATUITEMENT Windows Live Toolbar aujourd'hui !
http://toolbar.live.com

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