[Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Gilles Chanteperdrix]

Hi,

on some (all ?) platforms, we get a SIGILL when trying to emit the first 
Xenomai syscall, instead of the -ENOSYS return value. This patches 
handles the SIGILL by printing an error message and exiting.

Index: include/asm-generic/bits/bind.h
===================================================================
--- include/asm-generic/bits/bind.h	(revision 4175)
+++ include/asm-generic/bits/bind.h	(working copy)
@@ -9,6 +9,7 @@
 #include <signal.h>
 #include <pthread.h>
 #include <fcntl.h>
+#include <setjmp.h>
 #include <sys/ioctl.h>
 #include <sys/mman.h>
 #include <asm/xenomai/syscall.h>
@@ -17,6 +18,8 @@ __attribute__ ((weak))
 pthread_key_t xeno_current_key;
 __attribute__ ((weak))
 pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
+__attribute__ ((weak))
+jmp_buf xeno_sigill_jmpbuf;
 
 __attribute__ ((weak))
 void xeno_set_current(void)
@@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
 }
 #endif /* CONFIG_XENO_FASTSEM */
 
+void __attribute__((weak)) xeno_sigill_handler(int sig)
+{
+	siglongjmp(xeno_sigill_jmpbuf, 1);
+}
+
 static inline int
 xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)
 {
+	sighandler_t old_sigill_handler;
 	struct sigaction sa;
 	xnfeatinfo_t finfo;
 	int muxid;
 
+	old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
+	if (old_sigill_handler == SIG_ERR) {
+		perror("signal(SIGILL)");
+		exit(1);
+	}
+
+	if (sigsetjmp(xeno_sigill_jmpbuf, 1))
+		goto enosys;
+
 	muxid = XENOMAI_SYSBIND(skin_magic,
 				XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
 	switch (muxid) {
@@ -126,7 +144,7 @@ xeno_bind_skin(unsigned skin_magic, cons
 
 	case -ENOSYS:
 	case -ESRCH:
-
+	enosys:
 		fprintf(stderr,
 			"Xenomai: %s skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n"
 			"(modprobe %s?)\n", skin, module);
@@ -139,6 +157,8 @@ xeno_bind_skin(unsigned skin_magic, cons
 		exit(1);
 	}
 
+	signal(SIGILL, old_sigill_handler);
+
 #ifdef xeno_arch_features_check
 	xeno_arch_features_check();
 #endif /* xeno_arch_features_check */
@@ -180,9 +200,19 @@ xeno_bind_skin(unsigned skin_magic, cons
 static inline int
 xeno_bind_skin_opt(unsigned skin_magic, const char *skin, const char *module)
 {
+	sighandler_t old_sigill_handler;
 	xnfeatinfo_t finfo;
 	int muxid;
 
+	old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
+	if (old_sigill_handler == SIG_ERR) {
+		perror("signal(SIGILL)");
+		exit(1);
+	}
+
+	if (sigsetjmp(xeno_sigill_jmpbuf, 1))
+		goto enosys;
+
 	muxid = XENOMAI_SYSBIND(skin_magic,
 				XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
 	switch (muxid) {
@@ -203,7 +233,7 @@ xeno_bind_skin_opt(unsigned skin_magic, 
 
 	case -ENOSYS:
 	case -ESRCH:
-
+	enosys:
 		return -1;
 	}
 
@@ -213,6 +243,8 @@ xeno_bind_skin_opt(unsigned skin_magic, 
 		exit(1);
 	}
 
+	signal(SIGILL, old_sigill_handler);
+
 #ifdef xeno_arch_features_check
 	xeno_arch_features_check();
 #endif /* xeno_arch_features_check */



-- 
					    Gilles.

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Hi,
> 
> on some (all ?) platforms, we get a SIGILL when trying to emit the first 
> Xenomai syscall, instead of the -ENOSYS return value. This patches 
> handles the SIGILL by printing an error message and exiting.
> 

This is an issue for archs that encode the syscall number into the trap opcode
like ARM using the OABI, others will get -ENOSYS as expected, so this should
move to the arch-specific code.

> Index: include/asm-generic/bits/bind.h
> ===================================================================
> --- include/asm-generic/bits/bind.h	(revision 4175)
> +++ include/asm-generic/bits/bind.h	(working copy)
> @@ -9,6 +9,7 @@
>  #include <signal.h>
>  #include <pthread.h>
>  #include <fcntl.h>
> +#include <setjmp.h>

Oh dear... Yeah, this should really be buried into the ARM support code.

>  #include <sys/ioctl.h>
>  #include <sys/mman.h>
>  #include <asm/xenomai/syscall.h>
> @@ -17,6 +18,8 @@ __attribute__ ((weak))
>  pthread_key_t xeno_current_key;
>  __attribute__ ((weak))
>  pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
> +__attribute__ ((weak))
> +jmp_buf xeno_sigill_jmpbuf;
>  
>  __attribute__ ((weak))
>  void xeno_set_current(void)
> @@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
>  }
>  #endif /* CONFIG_XENO_FASTSEM */
>  
> +void __attribute__((weak)) xeno_sigill_handler(int sig)
> +{
> +	siglongjmp(xeno_sigill_jmpbuf, 1);
> +}
> +
>  static inline int
>  xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)
>  {
> +	sighandler_t old_sigill_handler;
>  	struct sigaction sa;
>  	xnfeatinfo_t finfo;
>  	int muxid;
>  
> +	old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
> +	if (old_sigill_handler == SIG_ERR) {
> +		perror("signal(SIGILL)");
> +		exit(1);
> +	}
> +
> +	if (sigsetjmp(xeno_sigill_jmpbuf, 1))
> +		goto enosys;
> +
>  	muxid = XENOMAI_SYSBIND(skin_magic,
>  				XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
>  	switch (muxid) {
> @@ -126,7 +144,7 @@ xeno_bind_skin(unsigned skin_magic, cons
>  
>  	case -ENOSYS:
>  	case -ESRCH:
> -
> +	enosys:
>  		fprintf(stderr,
>  			"Xenomai: %s skin or CONFIG_XENO_OPT_PERVASIVE disabled.\n"
>  			"(modprobe %s?)\n", skin, module);
> @@ -139,6 +157,8 @@ xeno_bind_skin(unsigned skin_magic, cons
>  		exit(1);
>  	}
>  
> +	signal(SIGILL, old_sigill_handler);
> +
>  #ifdef xeno_arch_features_check
>  	xeno_arch_features_check();
>  #endif /* xeno_arch_features_check */
> @@ -180,9 +200,19 @@ xeno_bind_skin(unsigned skin_magic, cons
>  static inline int
>  xeno_bind_skin_opt(unsigned skin_magic, const char *skin, const char *module)
>  {
> +	sighandler_t old_sigill_handler;
>  	xnfeatinfo_t finfo;
>  	int muxid;
>  
> +	old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
> +	if (old_sigill_handler == SIG_ERR) {
> +		perror("signal(SIGILL)");
> +		exit(1);
> +	}
> +
> +	if (sigsetjmp(xeno_sigill_jmpbuf, 1))
> +		goto enosys;
> +
>  	muxid = XENOMAI_SYSBIND(skin_magic,
>  				XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
>  	switch (muxid) {
> @@ -203,7 +233,7 @@ xeno_bind_skin_opt(unsigned skin_magic, 
>  
>  	case -ENOSYS:
>  	case -ESRCH:
> -
> +	enosys:
>  		return -1;
>  	}
>  
> @@ -213,6 +243,8 @@ xeno_bind_skin_opt(unsigned skin_magic, 
>  		exit(1);
>  	}
>  
> +	signal(SIGILL, old_sigill_handler);
> +
>  #ifdef xeno_arch_features_check
>  	xeno_arch_features_check();
>  #endif /* xeno_arch_features_check */
> 
> 
> 


-- 
Philippe.

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> on some (all ?) platforms, we get a SIGILL when trying to emit the first 
>> Xenomai syscall, instead of the -ENOSYS return value. This patches 
>> handles the SIGILL by printing an error message and exiting.
>>
> 
> This is an issue for archs that encode the syscall number into the trap opcode
> like ARM using the OABI, others will get -ENOSYS as expected, so this should
> move to the arch-specific code.

Actually, I get a SIGILL on ARM compiled with EABI as well. Moving this
code to the arch dependent code looks hard, since we need to setup the
jump buffer in the very function which issues the syscall (Ok, we could
use a macro). But what would you think of a SIGILL handler which does
not longjmp (like Jan suggested, simply print an error message and exit,
even if xeno_bind_skin_opt was called) ?

-- 
                                                 Gilles.

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> on some (all ?) platforms, we get a SIGILL when trying to emit the first 
>>> Xenomai syscall, instead of the -ENOSYS return value. This patches 
>>> handles the SIGILL by printing an error message and exiting.
>>>
>> This is an issue for archs that encode the syscall number into the trap opcode
>> like ARM using the OABI, others will get -ENOSYS as expected, so this should
>> move to the arch-specific code.
> 
> Actually, I get a SIGILL on ARM compiled with EABI as well. Moving this
> code to the arch dependent code looks hard, since we need to setup the
> jump buffer in the very function which issues the syscall (Ok, we could
> use a macro). But what would you think of a SIGILL handler which does
> not longjmp (like Jan suggested, simply print an error message and exit,
> even if xeno_bind_skin_opt was called) ?
> 

So, here is another version.

Index: include/asm-generic/bits/bind.h
===================================================================
--- include/asm-generic/bits/bind.h	(revision 4175)
+++ include/asm-generic/bits/bind.h	(working copy)
@@ -99,15 +99,32 @@ static void unmap_sem_heap(unsigned long
 }
 #endif /* CONFIG_XENO_FASTSEM */
 
+void __attribute__((weak)) xeno_sigill_handler(int sig)
+{
+	fprintf(stderr, "Xenomai or CONFIG_XENO_OPT_PERVASIVE disabled.\n"
+		"(modprobe xeno_nucleus?)\n");
+	exit(1);
+}
+
 static inline int
 xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)
 {
+	sighandler_t old_sigill_handler;
 	struct sigaction sa;
 	xnfeatinfo_t finfo;
 	int muxid;
 
+	old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
+	if (old_sigill_handler == SIG_ERR) {
+		perror("signal(SIGILL)");
+		exit(1);
+	}
+
 	muxid = XENOMAI_SYSBIND(skin_magic,
 				XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
+
+	signal(SIGILL, old_sigill_handler);
+
 	switch (muxid) {
 	case -EINVAL:
 
@@ -180,11 +197,21 @@ xeno_bind_skin(unsigned skin_magic, cons
 static inline int
 xeno_bind_skin_opt(unsigned skin_magic, const char *skin, const char *module)
 {
+	sighandler_t old_sigill_handler;
 	xnfeatinfo_t finfo;
 	int muxid;
 
+	old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
+	if (old_sigill_handler == SIG_ERR) {
+		perror("signal(SIGILL)");
+		exit(1);
+	}
+
 	muxid = XENOMAI_SYSBIND(skin_magic,
 				XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
+
+	signal(SIGILL, old_sigill_handler);
+
 	switch (muxid) {
 	case -EINVAL:
 

-- 
					    Gilles.

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> on some (all ?) platforms, we get a SIGILL when trying to emit the first 
>>> Xenomai syscall, instead of the -ENOSYS return value. This patches 
>>> handles the SIGILL by printing an error message and exiting.
>>>
>> This is an issue for archs that encode the syscall number into the trap opcode
>> like ARM using the OABI, others will get -ENOSYS as expected, so this should
>> move to the arch-specific code.
> 
> Actually, I get a SIGILL on ARM compiled with EABI as well.

It seems the ARM folks decided to send SIGILL with EABI to conform to the OABI
behaviour, despite they did not formally need that. Only invalid calls in the
9f00xx..9f07ff range are expected to return -ENOSYS. Too bad that our syscall
marker is out of that range.

 Moving this
> code to the arch dependent code looks hard, since we need to setup the
> jump buffer in the very function which issues the syscall (Ok, we could
> use a macro). But what would you think of a SIGILL handler which does
> not longjmp (like Jan suggested, simply print an error message and exit,
> even if xeno_bind_skin_opt was called) ?
> 

Fine with me.

-- 
Philippe.

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Hi,
>>>>
>>>> on some (all ?) platforms, we get a SIGILL when trying to emit the first 
>>>> Xenomai syscall, instead of the -ENOSYS return value. This patches 
>>>> handles the SIGILL by printing an error message and exiting.
>>>>
>>> This is an issue for archs that encode the syscall number into the trap opcode
>>> like ARM using the OABI, others will get -ENOSYS as expected, so this should
>>> move to the arch-specific code.
>> Actually, I get a SIGILL on ARM compiled with EABI as well.
> 
> It seems the ARM folks decided to send SIGILL with EABI to conform to the OABI
> behaviour, despite they did not formally need that. Only invalid calls in the
> 9f00xx..9f07ff range are expected to return -ENOSYS. Too bad that our syscall
> marker is out of that range.
> 
>  Moving this
>> code to the arch dependent code looks hard, since we need to setup the
>> jump buffer in the very function which issues the syscall (Ok, we could
>> use a macro). But what would you think of a SIGILL handler which does
>> not longjmp (like Jan suggested, simply print an error message and exit,
>> even if xeno_bind_skin_opt was called) ?
>>
> 
> Fine with me.

Ok. Commited in trunk. Do I commit in v2.4.x branch?

-- 
					    Gilles.

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> Philippe Gerum wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Hi,
>>>>>
>>>>> on some (all ?) platforms, we get a SIGILL when trying to emit the first 
>>>>> Xenomai syscall, instead of the -ENOSYS return value. This patches 
>>>>> handles the SIGILL by printing an error message and exiting.
>>>>>
>>>> This is an issue for archs that encode the syscall number into the trap opcode
>>>> like ARM using the OABI, others will get -ENOSYS as expected, so this should
>>>> move to the arch-specific code.
>>> Actually, I get a SIGILL on ARM compiled with EABI as well.
>> It seems the ARM folks decided to send SIGILL with EABI to conform to the OABI
>> behaviour, despite they did not formally need that. Only invalid calls in the
>> 9f00xx..9f07ff range are expected to return -ENOSYS. Too bad that our syscall
>> marker is out of that range.
>>
>>  Moving this
>>> code to the arch dependent code looks hard, since we need to setup the
>>> jump buffer in the very function which issues the syscall (Ok, we could
>>> use a macro). But what would you think of a SIGILL handler which does
>>> not longjmp (like Jan suggested, simply print an error message and exit,
>>> even if xeno_bind_skin_opt was called) ?
>>>
>> Fine with me.
> 
> Ok. Commited in trunk. Do I commit in v2.4.x branch?
> 

Yep. Thanks.

-- 
Philippe.

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Hi,
> 
> on some (all ?) platforms, we get a SIGILL when trying to emit the first 

I don't see this on x86, though.

> Xenomai syscall, instead of the -ENOSYS return value. This patches 
> handles the SIGILL by printing an error message and exiting.
> 
> Index: include/asm-generic/bits/bind.h
> ===================================================================
> --- include/asm-generic/bits/bind.h	(revision 4175)
> +++ include/asm-generic/bits/bind.h	(working copy)
> @@ -9,6 +9,7 @@
>  #include <signal.h>
>  #include <pthread.h>
>  #include <fcntl.h>
> +#include <setjmp.h>
>  #include <sys/ioctl.h>
>  #include <sys/mman.h>
>  #include <asm/xenomai/syscall.h>
> @@ -17,6 +18,8 @@ __attribute__ ((weak))
>  pthread_key_t xeno_current_key;
>  __attribute__ ((weak))
>  pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
> +__attribute__ ((weak))
> +jmp_buf xeno_sigill_jmpbuf;
>  
>  __attribute__ ((weak))
>  void xeno_set_current(void)
> @@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
>  }
>  #endif /* CONFIG_XENO_FASTSEM */
>  
> +void __attribute__((weak)) xeno_sigill_handler(int sig)
> +{
> +	siglongjmp(xeno_sigill_jmpbuf, 1);
> +}
> +

Just one question: Can we safely assume that sigsetjmp&siglongjump are
always available, also in uclibc environments e.g.?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> on some (all ?) platforms, we get a SIGILL when trying to emit the first 
> 
> I don't see this on x86, though.
> 
>> Xenomai syscall, instead of the -ENOSYS return value. This patches 
>> handles the SIGILL by printing an error message and exiting.
>>
>> Index: include/asm-generic/bits/bind.h
>> ===================================================================
>> --- include/asm-generic/bits/bind.h	(revision 4175)
>> +++ include/asm-generic/bits/bind.h	(working copy)
>> @@ -9,6 +9,7 @@
>>  #include <signal.h>
>>  #include <pthread.h>
>>  #include <fcntl.h>
>> +#include <setjmp.h>
>>  #include <sys/ioctl.h>
>>  #include <sys/mman.h>
>>  #include <asm/xenomai/syscall.h>
>> @@ -17,6 +18,8 @@ __attribute__ ((weak))
>>  pthread_key_t xeno_current_key;
>>  __attribute__ ((weak))
>>  pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
>> +__attribute__ ((weak))
>> +jmp_buf xeno_sigill_jmpbuf;
>>  
>>  __attribute__ ((weak))
>>  void xeno_set_current(void)
>> @@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
>>  }
>>  #endif /* CONFIG_XENO_FASTSEM */
>>  
>> +void __attribute__((weak)) xeno_sigill_handler(int sig)
>> +{
>> +	siglongjmp(xeno_sigill_jmpbuf, 1);
>> +}
>> +
> 
> Just one question: Can we safely assume that sigsetjmp&siglongjump are
> always available, also in uclibc environments e.g.?

Ok. We can use setjmp/longjmp and assume that only SIGILL is masked at
the longjmp call site ?

-- 
                                                 Gilles.

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> on some (all ?) platforms, we get a SIGILL when trying to emit the first 
>> I don't see this on x86, though.
>>
>>> Xenomai syscall, instead of the -ENOSYS return value. This patches 
>>> handles the SIGILL by printing an error message and exiting.
>>>
>>> Index: include/asm-generic/bits/bind.h
>>> ===================================================================
>>> --- include/asm-generic/bits/bind.h	(revision 4175)
>>> +++ include/asm-generic/bits/bind.h	(working copy)
>>> @@ -9,6 +9,7 @@
>>>  #include <signal.h>
>>>  #include <pthread.h>
>>>  #include <fcntl.h>
>>> +#include <setjmp.h>
>>>  #include <sys/ioctl.h>
>>>  #include <sys/mman.h>
>>>  #include <asm/xenomai/syscall.h>
>>> @@ -17,6 +18,8 @@ __attribute__ ((weak))
>>>  pthread_key_t xeno_current_key;
>>>  __attribute__ ((weak))
>>>  pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
>>> +__attribute__ ((weak))
>>> +jmp_buf xeno_sigill_jmpbuf;
>>>  
>>>  __attribute__ ((weak))
>>>  void xeno_set_current(void)
>>> @@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
>>>  }
>>>  #endif /* CONFIG_XENO_FASTSEM */
>>>  
>>> +void __attribute__((weak)) xeno_sigill_handler(int sig)
>>> +{
>>> +	siglongjmp(xeno_sigill_jmpbuf, 1);
>>> +}
>>> +
>> Just one question: Can we safely assume that sigsetjmp&siglongjump are
>> always available, also in uclibc environments e.g.?
> 
> Ok. We can use setjmp/longjmp and assume that only SIGILL is masked at
> the longjmp call site ?

Hmm, good question. But maybe this is a non-issue and sig{set|long}jmp
is actually always available (these days). On first glance, ucLibc seems
to have an implementation.

Alternative idea: What about defining a common xenomai_does_not_exist
service that warns and terminates? It could be called it both on ENOSYS
and from the signal handler.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Hi,
>>>>
>>>> on some (all ?) platforms, we get a SIGILL when trying to emit the first 
>>> I don't see this on x86, though.
>>>
>>>> Xenomai syscall, instead of the -ENOSYS return value. This patches 
>>>> handles the SIGILL by printing an error message and exiting.
>>>>
>>>> Index: include/asm-generic/bits/bind.h
>>>> ===================================================================
>>>> --- include/asm-generic/bits/bind.h	(revision 4175)
>>>> +++ include/asm-generic/bits/bind.h	(working copy)
>>>> @@ -9,6 +9,7 @@
>>>>  #include <signal.h>
>>>>  #include <pthread.h>
>>>>  #include <fcntl.h>
>>>> +#include <setjmp.h>
>>>>  #include <sys/ioctl.h>
>>>>  #include <sys/mman.h>
>>>>  #include <asm/xenomai/syscall.h>
>>>> @@ -17,6 +18,8 @@ __attribute__ ((weak))
>>>>  pthread_key_t xeno_current_key;
>>>>  __attribute__ ((weak))
>>>>  pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
>>>> +__attribute__ ((weak))
>>>> +jmp_buf xeno_sigill_jmpbuf;
>>>>  
>>>>  __attribute__ ((weak))
>>>>  void xeno_set_current(void)
>>>> @@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
>>>>  }
>>>>  #endif /* CONFIG_XENO_FASTSEM */
>>>>  
>>>> +void __attribute__((weak)) xeno_sigill_handler(int sig)
>>>> +{
>>>> +	siglongjmp(xeno_sigill_jmpbuf, 1);
>>>> +}
>>>> +
>>> Just one question: Can we safely assume that sigsetjmp&siglongjump are
>>> always available, also in uclibc environments e.g.?
>> Ok. We can use setjmp/longjmp and assume that only SIGILL is masked at
>> the longjmp call site ?
> 
> Hmm, good question. But maybe this is a non-issue and sig{set|long}jmp
> is actually always available (these days). On first glance, ucLibc seems
> to have an implementation.

We can also manually save and restore the signal mask.

> 
> Alternative idea: What about defining a common xenomai_does_not_exist
> service that warns and terminates? It could be called it both on ENOSYS
> and from the signal handler.

Yes, but in the xeno_bind_skin_opt case, we are expected to return a
status, and not exit. So, longjmp is the only way... Unless we accept to
 exit in the SIGILL case.

-- 
                                                 Gilles.