On 06/08/2012 11:20 AM, Philippe Gerum wrote:
> On 06/06/2012 08:00 PM, Gilles Chanteperdrix wrote:
>> 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).
>>
> 
> The only issue is with frame elimination starting with -O2 and above, 
> otherwise the backtraces are clean over gdb (just checked), at least 
> there does not seem to be any additional problem introduced by mixing bp 
> and no-bp. At any rate, -O0 -g is recommended to get clean and detailed 
> (back)traces anyway, and this is what we pick when --enable-debug is given.
> 
> We should move each existing inline XENOMAI_SYS/SKINCALL macro into its 
> own C trampoline, group all trampolines into separate compilation units, 
> and build each of these units with -fno-omit-frame-pointer unconditionally.
> 
> -forge is a good candidate for this, since the number of syscall 
> trampolines shrunk dramatically compared to 2.x. If any issue would be 
> easily detected based on the output of the new "slackspot" tracer we 
> have there.
> 
It looks to me like we can simply build xenomai libraries with
-fno-omit-frame-pointer, and compile the rest without this option. After
all, implementation of xenomai services are little more than syscall
trampolines.

-- 
                                            Gilles.

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Reply via email to