I will continue this topic since my problem looks similar.
I'm using linux kernel from *http://git.xenomai.org/ipipe-gch.git/* (ipipe
core-3.2 ) and xenomai 2.6 branch head. Compiling for versatile express
cortex-a9.
I tried to cross-compile a simple program bound_task (can be found in
documentation as example) but i received this:
*arm-unknown-linux-gnueabi-gcc -I/usr/xenomai/include -D_GNU_SOURCE
-D_REENTRANT -D__XENO__ -lnative -L/usr/xenomai/lib -lxenomai -lpthread
-lrt -lrtdk bound_task.c -o bound_task_VEXPRESS
In file included from /usr/xenomai/include/nucleus/trace.h:52,
from /usr/xenomai/include/nucleus/system.h:27,
from /usr/xenomai/include/asm/xenomai/system_64.h:137,
from /usr/xenomai/include/asm/xenomai/system.h:4,
from /usr/xenomai/include/nucleus/types.h:36,
from /usr/xenomai/include/nucleus/thread.h:25,
from /usr/xenomai/include/nucleus/sched.h:31,
from /usr/xenomai/include/native/task.h:25,
from bound_task.c:2:
/usr/xenomai/include/asm/xenomai/syscall.h: In function '__xn_rdtsc':
/usr/xenomai/include/asm/xenomai/syscall.h:327: warning: left shift count
>= width of type
/usr/xenomai/lib/libnative.so: file not recognized: File format not
recognized
collect2: ld returned 1 exit status
make: *** [bound_task] Error 1*
And as far as I'm concerned that means (the underlined line) that my
xenomai libraries are not cross-compiled for ARM (which now I assume have
to be) as well. I know that they are not, cause i omitted the
README.INSTALL of xenomai and run common *./configure* (which I assume
compiles xenomai for x86 or smth) instead of *./configure CFLAGS="...."
LDFLAGS="....." --build=i686-pc-linux-gnu --host=arm-unknown-linux-gnueabi *or
something similar. So I run the proper configure according to
README.INSTALL for ARM and this is what i receive:
*# ./configure CFLAGS="-march=armv7-a -mfpu=vfp3 *" LDFLAGS="-march=armv4t"
--build=i686-pc-linux-gnu --host=arm-unknown-linux-gnueabi
checking build system type... i686-pc-linux-gnu
checking host system type... arm-unknown-linux-gnueabi
checking for a BSD-compatible install... /usr/bin/install -c
checking for arm-unknown-linux-gnueabi-gcc... arm-unknown-linux-gnueabi-gcc
checking whether the C compiler works... no
configure: error: in `/home/marcin/arm/tarballs/xenomai-2.6-5942064':
configure: error: C compiler cannot create executables
See `config.log' for more details*
*
*I've already tried the *-fno-omit-frame-pointer *option and the result is
the same.
As I mentioned I'm compiling for cortex-a9 so the *CFLAGS *should be set as
omap4 setting? as long there is no cortex-a9 setting described...
*(CFLAGS="-march=armv7-a
-mfpu=vfp3 *")
*Any suggestions?
Thank you in advantage!
2012/6/9 ali hagigat <hagigat...@gmail.com>
> 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
>
--
Marcin Kuśka
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
