On 06/06/2012 07:57 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 05:21 PM, Philippe Gerum wrote:
>> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>>>> 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.
>>>>>>>
>>>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>>>
>>>>>
>>>>> In the mails following this one, I found how to fix the assembly to work
>>>>> in the omit-frame-pointer case. The real problem is that, at compilation
>>>>> time, we have no command-line #defined variable telling us whether
>>>>> compiling with frame pointers enabled. And it does not seem easy to
>>>>> write a configure test script, which tests whether frame pointers are
>>>>> enabled or not.
>>>>>
>>>>
>>>> I'd suggest that at some point, we move all the syscall trampolines out
>>>> of line, and specifically build the resulting file forcing
>>>> -fno-omit-frame-pointer. Such inlining will always be fragile until we
>>>> actually control the way that compilation unit is built, regardless of
>>>> the general settings for CFLAGS.
>>>>
>>> In the current 2.6 repository, we force -fno-omit-frame-pointer on x86_32.
>>>
>>
>> Yes, but that is crappy. The point is that we don't want to force this
>> for all userland bits. We'd only need this for syscall trampolines.
>>
> We currently have different flags for compiling xenomai than for passing
> to the applications (via xeno-config). The problem is that I am not sure
> it will not break for instance calling "backtrace" in gdb when breaking
> inside a xenomai function.
>
(mixing code compiled without frame pointers with code compiled with
frame pointers I mean).
--
Gilles.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
