This is the mail archive of the ecos-discuss@sourceware.org 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: how work synthetic for exceptions


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


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