From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15934 invoked by alias); 3 Apr 2008 13:24:31 -0000 Received: (qmail 15926 invoked by uid 22791); 3 Apr 2008 13:24:30 -0000 X-Spam-Check-By: sourceware.org Received: from snape.ecoscentric.com (HELO snape.ecoscentric.com) (212.13.207.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 13:24:02 +0000 Received: from localhost (snape.ecoscentric.com [127.0.0.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 64E81C540E1; Thu, 3 Apr 2008 14:23:59 +0100 (BST) Received: from snape.ecoscentric.com ([127.0.0.1]) by localhost (snape.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5jS1bSrxe43; Thu, 3 Apr 2008 14:23:55 +0100 (BST) Received: from delenn.bartv.net (unknown [212.13.207.199]) by snape.ecoscentric.com (Postfix) with ESMTP id E45ADC540D1; Thu, 3 Apr 2008 14:23:54 +0100 (BST) Date: Thu, 03 Apr 2008 14:08:00 -0000 Message-Id: From: Bart Veer To: trollepi jj CC: ecos-discuss@ecos.sourceware.org In-reply-to: (message from trollepi jj on Thu, 3 Apr 2008 13:00:03 +0100) References: Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] how work synthetic for exceptions X-SW-Source: 2008-04/txt/msg00048.txt.bz2 >>>>> "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