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.
-- Gilles. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai