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