Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Petr Cervenka wrote:
>>>> Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
>>>> identify which spot returns -EFAULT. I can't reproduce this issue on a
>>>> ppc target; I may try over x86 later, but this would speed up things if
>>>> you could spot the failing test before I'm able to switch to this.
>>>>
>>> Meanwhile I tried to mess little bit with rt_task_shadow() function to see, where is the source of -EFAULT. I planned to continue to follow it inside syscall etc.
>>> But most attempts to confirm, that the value is returned by line:
>>> 	err = XENOMAI_SKINCALL2(__native_muxid, __native_task_create, &bulk,
>>> 				NULL);
>> This branches to __rt_task_create in kernel space.
>>
> 
> The bulk variable is totally wrong in kernel space:
> for example (2, 0, 0, 0, 0, 134217728), perhaps always same values. Value 2 could be number of arguments of the skincall.
> It fails on following line (syscall.c:aprox. 193):
> 	if (__xn_safe_copy_to_user((void __user *)bulk.a1, &ph, sizeof(ph))) {
> 
>>> where suprisingly followed by correct behavior. For example following (nothing doing) change in the attached patch solves the whole thing:
>>> --- /usr/src/xenomai/src/skins/native/task2.c   2009-04-13 19:20:18.000000000 +0200
>>> +++ /usr/src/xenomai/src/skins/native/task.c    2009-07-17 15:06:20.000000000 +0200
>>> @@ -241,6 +241,7 @@
>>>         pthread_setspecific(__native_tskey, NULL);
>>>         free(self);
>>>  #endif /* !HAVE___THREAD */
>>> +       rt_task_set_mode(0, 0, NULL);
>>>         return err;
>>>  }
>>>
>>> objdumps of original and changed rt_task_shadow() is in attachment
>>>
>>> I will continue in research, but I'm really not good in dissasembling nor the register knowledge.
>>>
>> Try rebuilding the user-space libs passing --without-__thread to the
>> configure script.
>>
> 
> After rebuilding with "./configure --enable-smp --without-__thread" it works without any problems.
> Do you already know, where the problem is? What does the "--without-__thread" argument mean?

It's reproducible, will try to understand it. It's either a compiler bug
(your kubuntu version is fairly old and also unsupported due to security
flaws), or we actually still have a problems around TLS variables
(Thread Local Storage, that's what --without-__thread disables).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]