I did "make clean" for building the Xenomai user space components and now every thing seems OK. Xenomai version is 2.6.0.
Thank you. On Fri, Jun 8, 2012 at 2:05 PM, Gilles Chanteperdrix <gilles.chanteperd...@xenomai.org> wrote: > On 06/08/2012 11:31 AM, Philippe Gerum wrote: >> On 06/08/2012 11:29 AM, Philippe Gerum wrote: >>> On 06/08/2012 11:25 AM, Gilles Chanteperdrix wrote: >>>> 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. >>>> >>> >>> This is true for 2.x, however -forge will need the other approach. >>> >> >> Unless you only mean lib/cobalt for 3.x, in which case I would agree. >> > I was thinking 2.x. But yes, we can do the same with lib/cobalt. > > -- > Gilles. > > _______________________________________________ > Xenomai mailing list > Xenomai@xenomai.org > http://www.xenomai.org/mailman/listinfo/xenomai _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
