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.

--
Philippe.

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

Reply via email to