On 06/06/2012 03:53 PM, Philippe Gerum wrote:
> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>> command:
>>>>>>>
>>>>>>
>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>
>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>
>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>> index 7a338a0..9c7849e 100644
>>>>> --- a/src/skins/posix/init.c
>>>>> +++ b/src/skins/posix/init.c
>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>> static __attribute__ ((constructor))
>>>>> void __init_posix_interface(void)
>>>>> {
>>>>> + volatile pthread_t tid = pthread_self();
>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>> struct sched_param parm;
>>>>> int policy;
>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>
>>>>> /* Don't use auto-shadowing if we are likely invoked from
>>>>> dlopen. */
>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>> - err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>> + err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>> if (err) {
>>>>> fprintf(stderr, "Xenomai Posix skin init: "
>>>>> "pthread_getschedparam: %s\n", strerror(err));
>>>>> exit(EXIT_FAILURE);
>>>>> }
>>>>>
>>>>> - err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>> + err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>> if (err) {
>>>>> fprintf(stderr, "Xenomai Posix skin init: "
>>>>> "pthread_setschedparam: %s\n", strerror(err));
>>>>
>>>> There should not be any issue here, as the pthread_self() is passed as
>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>
>>>
>>> Did you get any disassembly of the faulty code when suggesting
>>> -fno-omit-frame-pointer last time you did?
>>>
>> No, but I had experienced the problem first hand.
>>
>
> It would be interesting to know why we have to force a frame pointer in
> there. I'm not comfortable with voodoo fixing, that bug might bite later
> on as gcc's optimizer is unlikely to become less aggressive over time.
>
Ah this, I know. I have posted a mail where I explained the problem. I
am a bit in a short schedule here, will post the link tonight.
--
Gilles.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
