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