From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4D513278.4090606@domain.hid> Date: Tue, 08 Feb 2011 13:09:28 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4D5039AD.2070205@domain.hid> <4D50433D.1040804@domain.hid> <1297154320.2023.6.camel@domain.hid> <1297156556.2023.9.camel@domain.hid> In-Reply-To: <1297156556.2023.9.camel@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Exception handlers in primary domain / user-space signals List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: xenomai@xenomai.org Philippe Gerum wrote: > On Tue, 2011-02-08 at 10:10 +0100, Henri Roosen wrote: >> On Tue, Feb 8, 2011 at 9:38 AM, Philippe Gerum wrote: >>> On Tue, 2011-02-08 at 09:21 +0100, Henri Roosen wrote: >>>> On Mon, Feb 7, 2011 at 8:08 PM, Gilles Chanteperdrix >>>> wrote: >>>>> Henri Roosen wrote: >>>>>> On Mon, Feb 7, 2011 at 7:27 PM, Gilles Chanteperdrix >>>>>> wrote: >>>>>>> Henri Roosen wrote: >>>>>>>> We are using signal handlers for catching exceptions which our >>>>>>>> application is allowed to make and which we know how to handle. >>>>>>>> >>>>>>>> The current Xenomai implementation is to switch to the secondary >>>>>>>> domain and call the handlers from there. >>>>>>>> Unfortunately this takes too much time for our application and we >>>>>>>> would like to handle the exception without the switch to the secondary >>>>>>>> domain, in primary domain. >>>>>>>> >>>>>>>> Can anyone give some advice how to implement that? >>>>>>>> Will "user-space signals" which was planned for Xenomai 2.6 fulfill this need? >>>>>>>> Is there already code available for user-space signals? >>>>>>> In the 2.5 series, we added some code to support signals. The signals >>>>>>> are multiplexed per-skin in kernel-space, and demultiplexed in >>>>>>> user-space, upon exit of system calls. We implemented a unit test of >>>>>>> this functionality with the "sigtest" skin and user-space test, but they >>>>>>> only work upon return from system calls. >>>>>>> >>>>>>> Then we added support for the "mayday" page, which made us realize, that >>>>>>> maybe implementing signals handling at any time, not only when returning >>>>>>> from system calls, was possible. But then came the realization that in >>>>>>> order to implement that, we would have to fiddle with the FPU, which is >>>>>>> an area where we have a certain tradition for not getting the things >>>>>>> right at the first attempt. So, we kind of stopped here. >>>>>>> >>>>>>> So, if you want some ad-hoc signals upon return from system call, the >>>>>>> task is pretty easy. If you want the full posix signals interface, then >>>>>>> things are going to be a bit harder. >>>>>>> >>>>>> I am afraid it's going to be a bit harder; we would need it when the >>>>>> exception occurs and that is in most cases not at a place in the code >>>>>> where there is a system call :-(. >>>>> What kind of exception is it? Could not the exception be signalled at >>>>> the next system call? >>>> Our customers provide the application code, we provide more or less >>>> the framework. Customers can install exception handlers for for >>>> instance floating point exceptions (SIGFPE). >>>> Besides that we provide a means of tracing the application code, which >>>> is handled by breakpoints in the code which then does some bookkeeping >>>> and lets the task run again. Of course that has some overhead also >>>> when using our old OS, but Linux-Xenomai has so much overhead because >>>> of the secondary domain switch. Therefore we would like to handle it >>>> in primary domain. >>> Connect a high priority shadow task in userland to an exception handler >>> installed in kernel space via some synchronization (semaphore, event, >>> whatever). The handler would be called upon exception, then would wake >>> up your task in userland, which would preempt immediately any other task >>> activity due to its higher priority. This would not entail any mode >>> switch, only a fast context switch between Xenomai contexts. >>> >>> Over this "exception server" task context, you should be able to execute >>> any kind of user-space handler to mimic the POSIX signal interface as >>> much as required. Of course this would not run over the faulting context >>> like POSIX signals do (unless SIGEV_THREAD is used), but this might be >>> ok for your purpose. >>> >> Unfortunately we do need the faulting context for the SIGFPE signal >> and SIGTRAP (x86) / SIGILL (arm) signals... > > > It's too much to ask in the current implementation. There is no quick > fix to this, I mean if you want to have a standard signal frame to > exploit in userland. Otherwise, you could pull some relevant bits from > the exception frame in kernel space (you have the struct pt_regs of the > faulting context avail there), and pass them through your > synchronization mechanism to userland, so as to fake some kind of > pseudo-signal frame. All this is certainly doable, but even without Xenomai, going to kernel-space in case of exception then building a signal frame, going back to user-space, executing the signal handler, then returning from the signal (possibly going to kernel-space again) is not exactly a light operation. So, surely, exceptions should remain exceptional and using them routinely does not look like the right thing to do. For the signals themselve: - implementing SIGFPE will require clearing up exceptions at the FPU level, which may not be easy, depending on the architecture; - what will you do with SIGTRAP, stop the task? Why would you need to remain in primary mode? - why do you get a SIGILL on ARM? This is an abnormal condition... -- Gilles.