* [Xenomai-core] gcc-4.6 issue @ 2011-08-11 10:59 Roland Stigge 2011-08-11 11:07 ` Gilles Chanteperdrix 0 siblings, 1 reply; 17+ messages in thread From: Roland Stigge @ 2011-08-11 10:59 UTC (permalink / raw) To: xenomai Hi, I remember the recent gcc 4.6 issue on this list, but unfortunately, didn't have much time for attention. Now, it found its way to the Debian package: http://bugs.debian.org/637425 I wonder if it is a compiler bug or Xenomai's. Thanks in advance, Roland ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 10:59 [Xenomai-core] gcc-4.6 issue Roland Stigge @ 2011-08-11 11:07 ` Gilles Chanteperdrix 2011-08-11 11:43 ` Daniele Nicolodi 0 siblings, 1 reply; 17+ messages in thread From: Gilles Chanteperdrix @ 2011-08-11 11:07 UTC (permalink / raw) To: Roland Stigge; +Cc: xenomai On 08/11/2011 12:59 PM, Roland Stigge wrote: > Hi, > > I remember the recent gcc 4.6 issue on this list, but unfortunately, > didn't have much time for attention. Now, it found its way to the Debian > package: http://bugs.debian.org/637425 > > I wonder if it is a compiler bug or Xenomai's. It looks like a xenomai bug due to the pseudo-signals implemented in this branch. I have asked two persons which have this compiler to test xenomai-head where these signals have been removed to confirm this hypothesis, but received no answer as of today. -- Gilles. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 11:07 ` Gilles Chanteperdrix @ 2011-08-11 11:43 ` Daniele Nicolodi 2011-08-11 14:48 ` Daniele Nicolodi 0 siblings, 1 reply; 17+ messages in thread From: Daniele Nicolodi @ 2011-08-11 11:43 UTC (permalink / raw) To: xenomai On 11/08/11 13:07, Gilles Chanteperdrix wrote: > On 08/11/2011 12:59 PM, Roland Stigge wrote: >> Hi, >> >> I remember the recent gcc 4.6 issue on this list, but unfortunately, >> didn't have much time for attention. Now, it found its way to the Debian >> package: http://bugs.debian.org/637425 >> >> I wonder if it is a compiler bug or Xenomai's. > > It looks like a xenomai bug due to the pseudo-signals implemented in > this branch. I have asked two persons which have this compiler to test > xenomai-head where these signals have been removed to confirm this > hypothesis, but received no answer as of today. Hello. I submitted the debian bug, beside what is the cause of the problem, binaries compiled with gcc-4.6 are not usable, but binaries compiled with gcc-4.4 are. I'm compiling xenomai-head right now (this requires compiling both user space and kernel space, so testing requires some more time). I'll let you know ASAP. Cheers, -- Daniele ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 11:43 ` Daniele Nicolodi @ 2011-08-11 14:48 ` Daniele Nicolodi 2011-08-11 17:21 ` Roland Stigge 2011-08-11 17:22 ` [Xenomai-core] " Gilles Chanteperdrix 0 siblings, 2 replies; 17+ messages in thread From: Daniele Nicolodi @ 2011-08-11 14:48 UTC (permalink / raw) To: xenomai On 11/08/11 13:43, Daniele Nicolodi wrote: > I submitted the debian bug, beside what is the cause of the problem, > binaries compiled with gcc-4.6 are not usable, but binaries compiled > with gcc-4.4 are. I'm compiling xenomai-head right now (this requires > compiling both user space and kernel space, so testing requires some > more time). I'll let you know ASAP. Hello, I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained kernel boots fine but xenomai services do not: latency hangs right after the sched_setscheduler system call. With the same kernel I compiled user space with gcc-4.4 and xenomia services work just fine. Cheers, -- Daniele ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 14:48 ` Daniele Nicolodi @ 2011-08-11 17:21 ` Roland Stigge 2011-08-11 17:31 ` Gilles Chanteperdrix 2011-08-11 17:22 ` [Xenomai-core] " Gilles Chanteperdrix 1 sibling, 1 reply; 17+ messages in thread From: Roland Stigge @ 2011-08-11 17:21 UTC (permalink / raw) To: xenomai; +Cc: 637425 [-- Attachment #1: Type: text/plain, Size: 716 bytes --] Hi, On 08/11/2011 04:48 PM, Daniele Nicolodi wrote: > I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained > kernel boots fine but xenomai services do not: latency hangs right after > the sched_setscheduler system call. With the same kernel I compiled user > space with gcc-4.4 and xenomia services work just fine. I can confirm this now for Debian. Sorry for the delay. Will use gcc-4.4 for building the Debian package for now. Attached is a patch you might like to integrate into the GIT repository for the build environment. BTW: You further don't need all the Makefile.in's under revision control when there's also a Makefile.am. Similarly regarding aclocal.m4 and configure. bye, Roland [-- Attachment #2: xenomai.patch --] [-- Type: text/x-patch, Size: 1060 bytes --] diff --git a/include/nucleus/Makefile.am b/include/nucleus/Makefile.am index 5fc1c21..7af212a 100644 --- a/include/nucleus/Makefile.am +++ b/include/nucleus/Makefile.am @@ -37,4 +37,5 @@ includesub_HEADERS = \ vdso.h \ seqlock.h \ version.h \ - xenomai.h + xenomai.h \ + vfile.h diff --git a/src/skins/common/Makefile.am b/src/skins/common/Makefile.am index 2156165..888bc5b 100644 --- a/src/skins/common/Makefile.am +++ b/src/skins/common/Makefile.am @@ -1,5 +1,7 @@ lib_LTLIBRARIES = libxenomai.la -noinst_HEADERS = sem_heap.h +noinst_HEADERS = \ + sem_heap.h \ + internal.h libxenomai_la_SOURCES = \ assert_context.c \ diff --git a/src/testsuite/xeno-test/Makefile.am b/src/testsuite/xeno-test/Makefile.am index 1d082de..1c8280c 100644 --- a/src/testsuite/xeno-test/Makefile.am +++ b/src/testsuite/xeno-test/Makefile.am @@ -9,4 +9,4 @@ xeno_test_run_CPPFLAGS = -DTESTDIR=\"$(testdir)\" xeno-test: $(srcdir)/xeno-test.in Makefile sed "s,@testdir@domain.hid)," $< > $@ -EXTRA_DIST = $(test_SCRIPTS) +EXTRA_DIST = $(test_SCRIPTS) xeno-test.in ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 17:21 ` Roland Stigge @ 2011-08-11 17:31 ` Gilles Chanteperdrix 2011-08-11 19:34 ` Gilles Chanteperdrix 2011-08-11 20:52 ` Gilles Chanteperdrix 0 siblings, 2 replies; 17+ messages in thread From: Gilles Chanteperdrix @ 2011-08-11 17:31 UTC (permalink / raw) To: Roland Stigge; +Cc: 637425, xenomai On 08/11/2011 07:21 PM, Roland Stigge wrote: > Hi, > > On 08/11/2011 04:48 PM, Daniele Nicolodi wrote: >> I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained >> kernel boots fine but xenomai services do not: latency hangs right after >> the sched_setscheduler system call. With the same kernel I compiled user >> space with gcc-4.4 and xenomia services work just fine. > > I can confirm this now for Debian. Sorry for the delay. > > Will use gcc-4.4 for building the Debian package for now. > > Attached is a patch you might like to integrate into the GIT repository > for the build environment. Thanks for the patch. > BTW: You further don't need all the > Makefile.in's under revision control when there's also a Makefile.am. > Similarly regarding aclocal.m4 and configure. Old debate, we want users to avoid having to install the autotools in order to compile from git, so, we put these files under revision control. It becomes more and more the sanest solution, as versions of the autotools are released which break backward compatibility. -- Gilles. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 17:31 ` Gilles Chanteperdrix @ 2011-08-11 19:34 ` Gilles Chanteperdrix 2011-08-11 20:52 ` Gilles Chanteperdrix 1 sibling, 0 replies; 17+ messages in thread From: Gilles Chanteperdrix @ 2011-08-11 19:34 UTC (permalink / raw) To: Roland Stigge; +Cc: xenomai On 08/11/2011 07:31 PM, Gilles Chanteperdrix wrote: > On 08/11/2011 07:21 PM, Roland Stigge wrote: >> Hi, >> >> On 08/11/2011 04:48 PM, Daniele Nicolodi wrote: >>> I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained >>> kernel boots fine but xenomai services do not: latency hangs right after >>> the sched_setscheduler system call. With the same kernel I compiled user >>> space with gcc-4.4 and xenomia services work just fine. >> >> I can confirm this now for Debian. Sorry for the delay. >> >> Will use gcc-4.4 for building the Debian package for now. >> >> Attached is a patch you might like to integrate into the GIT repository >> for the build environment. > > Thanks for the patch. > >> BTW: You further don't need all the >> Makefile.in's under revision control when there's also a Makefile.am. >> Similarly regarding aclocal.m4 and configure. > > Old debate, we want users to avoid having to install the autotools in > order to compile from git, so, we put these files under revision > control. It becomes more and more the sanest solution, as versions of > the autotools are released which break backward compatibility. > Sorry for the noise in debian bug tracker, I had not seen that it was in CC. -- Gilles. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 17:31 ` Gilles Chanteperdrix 2011-08-11 19:34 ` Gilles Chanteperdrix @ 2011-08-11 20:52 ` Gilles Chanteperdrix 2011-08-11 23:18 ` Gilles Chanteperdrix 1 sibling, 1 reply; 17+ messages in thread From: Gilles Chanteperdrix @ 2011-08-11 20:52 UTC (permalink / raw) To: Roland Stigge; +Cc: 637425, xenomai On 08/11/2011 07:31 PM, Gilles Chanteperdrix wrote: > On 08/11/2011 07:21 PM, Roland Stigge wrote: >> Hi, >> >> On 08/11/2011 04:48 PM, Daniele Nicolodi wrote: >>> I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained >>> kernel boots fine but xenomai services do not: latency hangs right after >>> the sched_setscheduler system call. With the same kernel I compiled user >>> space with gcc-4.4 and xenomia services work just fine. >> >> I can confirm this now for Debian. Sorry for the delay. >> >> Will use gcc-4.4 for building the Debian package for now. >> The gcc 4.6 version is compiled with frame pointer disabled, whereas the 4.4 version is compiled with frame pointers. Enabling the -fomit-frame-pointer option with gcc 4.4 seems to cause issues as well. With gcc 4.4, the difference is very visible in rt_task_start. The correct syscall chunk is: 11: 0d 2b 02 00 02 or $0x200022b,%eax Computes the syscall number, put the result in eax. 16: 89 45 fc mov %eax,-0x4(%ebp) Move the result from eax to temporary space on stack. 19: 8b 45 08 mov 0x8(%ebp),%eax Load syscall first argument value into eax 1c: 53 push %ebx 1d: 89 c3 mov %eax,%ebx Push ebx, move syscall first argument from eax to ebx 1f: 8b 45 fc mov -0x4(%ebp),%eax Reload the syscall number from its temporary storage to eax. 22: 65 ff 15 10 00 00 00 call *%gs:0x10 29: 5b pop %ebx Syscall done. The version without frame pointer: 4e3d: 8b 00 mov (%eax),%eax 4e3f: 0d 2b 02 00 02 or $0x200022b,%eax 4e44: 89 44 24 0c mov %eax,0xc(%esp) 4e48: 8b 44 24 18 mov 0x18(%esp),%eax 4e4c: 53 push %ebx 4e4d: 89 c3 mov %eax,%ebx 4e4f: 8b 44 24 0c mov 0xc(%esp),%eax 4e53: 65 ff 15 10 00 00 00 call *%gs:0x10 4e5a: 5b pop %ebx This is essentially the same sequence, except that the temporary storage used to store the syscall number is obtained via a relative offset of the stack pointer (esp) instead of a relative offset of the frame pointer, since we are compiling without frame pointers, the problem is that between the time this value is stored, and the time it is restored, the stack pointer changed since we pushed %ebx. So, I do not really know what to make of it. The simple solution seems to me to continue compiling with frame pointers. I.e. add -fno-omit-frame-pointer with gcc 4.6. -- Gilles. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 20:52 ` Gilles Chanteperdrix @ 2011-08-11 23:18 ` Gilles Chanteperdrix 2011-08-12 8:18 ` Daniele Nicolodi 2011-08-12 8:20 ` [Xenomai-core] Bug#637425: " Roland Stigge 0 siblings, 2 replies; 17+ messages in thread From: Gilles Chanteperdrix @ 2011-08-11 23:18 UTC (permalink / raw) To: Roland Stigge; +Cc: 637425, xenomai On 08/11/2011 10:52 PM, Gilles Chanteperdrix wrote: > On 08/11/2011 07:31 PM, Gilles Chanteperdrix wrote: >> On 08/11/2011 07:21 PM, Roland Stigge wrote: >>> Hi, >>> >>> On 08/11/2011 04:48 PM, Daniele Nicolodi wrote: >>>> I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained >>>> kernel boots fine but xenomai services do not: latency hangs right after >>>> the sched_setscheduler system call. With the same kernel I compiled user >>>> space with gcc-4.4 and xenomia services work just fine. >>> >>> I can confirm this now for Debian. Sorry for the delay. >>> >>> Will use gcc-4.4 for building the Debian package for now. >>> > > The gcc 4.6 version is compiled with frame pointer disabled, whereas the > 4.4 version is compiled with frame pointers. Enabling the > -fomit-frame-pointer option with gcc 4.4 seems to cause issues as well. > > With gcc 4.4, the difference is very visible in rt_task_start. The > correct syscall chunk is: > > 11: 0d 2b 02 00 02 or $0x200022b,%eax > > Computes the syscall number, put the result in eax. > > 16: 89 45 fc mov %eax,-0x4(%ebp) > > Move the result from eax to temporary space on stack. > > 19: 8b 45 08 mov 0x8(%ebp),%eax > > Load syscall first argument value into eax > > 1c: 53 push %ebx > 1d: 89 c3 mov %eax,%ebx > > Push ebx, move syscall first argument from eax to ebx > > 1f: 8b 45 fc mov -0x4(%ebp),%eax > > Reload the syscall number from its temporary storage to eax. > > 22: 65 ff 15 10 00 00 00 call *%gs:0x10 > 29: 5b pop %ebx > > Syscall done. > > The version without frame pointer: > 4e3d: 8b 00 mov (%eax),%eax > 4e3f: 0d 2b 02 00 02 or $0x200022b,%eax > 4e44: 89 44 24 0c mov %eax,0xc(%esp) > 4e48: 8b 44 24 18 mov 0x18(%esp),%eax > 4e4c: 53 push %ebx > 4e4d: 89 c3 mov %eax,%ebx > 4e4f: 8b 44 24 0c mov 0xc(%esp),%eax > 4e53: 65 ff 15 10 00 00 00 call *%gs:0x10 > 4e5a: 5b pop %ebx > > This is essentially the same sequence, except that the temporary storage > used to store the syscall number is obtained via a relative offset of > the stack pointer (esp) instead of a relative offset of the frame > pointer, since we are compiling without frame pointers, the problem is > that between the time this value is stored, and the time it is restored, > the stack pointer changed since we pushed %ebx. > > So, I do not really know what to make of it. The simple solution seems > to me to continue compiling with frame pointers. I.e. add > -fno-omit-frame-pointer with gcc 4.6. > The following patch seems to do the trick. It makes the assumption that when compiling with -fomit-frame-pointer, we have one more register, so the "R" constraint will always be able to avoid choosing eax, and eax will be free for the muxcode, so that the compiler will not choose the "m" alternative. diff --git a/include/asm-x86/syscall.h b/include/asm-x86/syscall.h index 3beb1ca..e51aa86 100644 --- a/include/asm-x86/syscall.h +++ b/include/asm-x86/syscall.h @@ -157,8 +157,8 @@ static inline void __xn_get_ebp(void **dest) "movl %1, %%eax\n\t" \ DOSYSCALL \ RESTOREARGS_##nr \ - : "=a" (__resultvar) \ - : "i" (__xn_mux_code(0, op)) ASMFMT_##nr(args) \ + : "=a,a" (__resultvar) \ + : "i,i" (__xn_mux_code(0, op)) ASMFMT_##nr(args) \ : "memory", "cc"); \ (int) __resultvar; \ }) @@ -171,8 +171,8 @@ static inline void __xn_get_ebp(void **dest) "movl %1, %%eax\n\t" \ DOSYSCALLSAFE \ RESTOREARGS_##nr \ - : "=a" (__resultvar) \ - : "i" (__xn_mux_code(0, op)) ASMFMT_##nr(args) \ + : "=a,a" (__resultvar) \ + : "i,i" (__xn_mux_code(0, op)) ASMFMT_##nr(args) \ : "memory", "cc"); \ (int) __resultvar; \ }) @@ -186,8 +186,8 @@ static inline void __xn_get_ebp(void **dest) "movl %1, %%eax\n\t" \ DOSYSCALL \ RESTOREARGS_##nr \ - : "=a" (__resultvar) \ - : "m" (__muxcode) ASMFMT_##nr(args) \ + : "=a,a" (__resultvar) \ + : "a,m" (__muxcode) ASMFMT_##nr(args) \ : "memory", "cc"); \ (int) __resultvar; \ }) @@ -211,15 +211,15 @@ static inline void __xn_get_ebp(void **dest) #define ASMFMT_0() #define ASMFMT_1(arg1) \ - , "acdSD" (arg1) + , "R,R" (arg1) #define ASMFMT_2(arg1, arg2) \ - , "adSD" (arg1), "c" (arg2) + , "R,R" (arg1), "c,c" (arg2) #define ASMFMT_3(arg1, arg2, arg3) \ - , "aSD" (arg1), "c" (arg2), "d" (arg3) + , "R,R" (arg1), "c,c" (arg2), "d,d" (arg3) #define ASMFMT_4(arg1, arg2, arg3, arg4) \ - , "aD" (arg1), "c" (arg2), "d" (arg3), "S" (arg4) + , "R,R" (arg1), "c,c" (arg2), "d,d" (arg3), "S,S" (arg4) #define ASMFMT_5(arg1, arg2, arg3, arg4, arg5) \ - , "a" (arg1), "c" (arg2), "d" (arg3), "S" (arg4), "D" (arg5) + , "R,R" (arg1), "c,c" (arg2), "d,d" (arg3), "S,S" (arg4), "D,D" (arg5) #define XENOMAI_SYSBIND(a1,a2,a3,a4) \ XENOMAI_SYS_MUX_SAFE(4,__xn_sys_bind,a1,a2,a3,a4) -- Gilles. ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 23:18 ` Gilles Chanteperdrix @ 2011-08-12 8:18 ` Daniele Nicolodi 2011-08-12 8:46 ` Gilles Chanteperdrix 2011-08-12 10:08 ` Daniele Nicolodi 2011-08-12 8:20 ` [Xenomai-core] Bug#637425: " Roland Stigge 1 sibling, 2 replies; 17+ messages in thread From: Daniele Nicolodi @ 2011-08-12 8:18 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: 637425, xenomai On 12/08/11 01:18, Gilles Chanteperdrix wrote: > The following patch seems to do the trick. It makes the assumption that > when compiling with -fomit-frame-pointer, we have one more register, so > the "R" constraint will always be able to avoid choosing eax, and eax > will be free for the muxcode, so that the compiler will not choose the > "m" alternative. It works, indeed. Thank you Gilles. May this patch be backported to the stable branch? Cheers, -- Daniele ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-12 8:18 ` Daniele Nicolodi @ 2011-08-12 8:46 ` Gilles Chanteperdrix 2011-08-12 10:08 ` Daniele Nicolodi 1 sibling, 0 replies; 17+ messages in thread From: Gilles Chanteperdrix @ 2011-08-12 8:46 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: xenomai Daniele Nicolodi wrote: > On 12/08/11 01:18, Gilles Chanteperdrix wrote: >> The following patch seems to do the trick. It makes the assumption that >> when compiling with -fomit-frame-pointer, we have one more register, so >> the "R" constraint will always be able to avoid choosing eax, and eax >> will be free for the muxcode, so that the compiler will not choose the >> "m" alternative. > > It works, indeed. Thank you Gilles. > > May this patch be backported to the stable branch? I do not think so, simply compile with -fno-omit-frame-pointer. -- Gilles. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-12 8:18 ` Daniele Nicolodi 2011-08-12 8:46 ` Gilles Chanteperdrix @ 2011-08-12 10:08 ` Daniele Nicolodi 2011-08-12 10:11 ` Gilles Chanteperdrix 1 sibling, 1 reply; 17+ messages in thread From: Daniele Nicolodi @ 2011-08-12 10:08 UTC (permalink / raw) To: xenomai On 12/08/11 10:18, Daniele Nicolodi wrote: > On 12/08/11 01:18, Gilles Chanteperdrix wrote: >> The following patch seems to do the trick. It makes the assumption that >> when compiling with -fomit-frame-pointer, we have one more register, so >> the "R" constraint will always be able to avoid choosing eax, and eax >> will be free for the muxcode, so that the compiler will not choose the >> "m" alternative. > > It works, indeed. Thank you Gilles. I've spoken to early. The patch does not work for the posix skin. Posix skin services return "function not implemented" errors when xenomai user space is compiled with the patch and gcc-4.6, they work just fine when compiled with gcc-4.4 (without the patch). Cheers, -- Daniele ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-12 10:08 ` Daniele Nicolodi @ 2011-08-12 10:11 ` Gilles Chanteperdrix 0 siblings, 0 replies; 17+ messages in thread From: Gilles Chanteperdrix @ 2011-08-12 10:11 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: xenomai Daniele Nicolodi wrote: > On 12/08/11 10:18, Daniele Nicolodi wrote: >> On 12/08/11 01:18, Gilles Chanteperdrix wrote: >>> The following patch seems to do the trick. It makes the assumption that >>> when compiling with -fomit-frame-pointer, we have one more register, so >>> the "R" constraint will always be able to avoid choosing eax, and eax >>> will be free for the muxcode, so that the compiler will not choose the >>> "m" alternative. >> >> It works, indeed. Thank you Gilles. > > I've spoken to early. The patch does not work for the posix skin. > Posix skin services return "function not implemented" errors when > xenomai user space is compiled with the patch and gcc-4.6, they work > just fine when compiled with gcc-4.4 (without the patch). Not really surprising. Then just compile with -fno-omit-frame-pointer. -- Gilles. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] Bug#637425: gcc-4.6 issue 2011-08-11 23:18 ` Gilles Chanteperdrix 2011-08-12 8:18 ` Daniele Nicolodi @ 2011-08-12 8:20 ` Roland Stigge 1 sibling, 0 replies; 17+ messages in thread From: Roland Stigge @ 2011-08-12 8:20 UTC (permalink / raw) To: 637425; +Cc: xenomai Hi, On 08/12/2011 01:18 AM, Gilles Chanteperdrix wrote: > The following patch seems to do the trick. It makes the assumption that > when compiling with -fomit-frame-pointer, we have one more register, so > the "R" constraint will always be able to avoid choosing eax, and eax > will be free for the muxcode, so that the compiler will not choose the > "m" alternative. Thanks for the update! I can confirm that both the patch for xenomai-head and -fno-omit-frame-pointer fix the problem. For Debian's xenomai 2.5.6, I will just use -fno-omit-frame-pointer for now. bye, Roland ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 14:48 ` Daniele Nicolodi 2011-08-11 17:21 ` Roland Stigge @ 2011-08-11 17:22 ` Gilles Chanteperdrix 2011-08-11 18:42 ` Daniele Nicolodi 1 sibling, 1 reply; 17+ messages in thread From: Gilles Chanteperdrix @ 2011-08-11 17:22 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: xenomai On 08/11/2011 04:48 PM, Daniele Nicolodi wrote: > On 11/08/11 13:43, Daniele Nicolodi wrote: >> I submitted the debian bug, beside what is the cause of the problem, >> binaries compiled with gcc-4.6 are not usable, but binaries compiled >> with gcc-4.4 are. I'm compiling xenomai-head right now (this requires >> compiling both user space and kernel space, so testing requires some >> more time). I'll let you know ASAP. > > Hello, > > I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained > kernel boots fine but xenomai services do not: latency hangs right after > the sched_setscheduler system call. With the same kernel I compiled user > space with gcc-4.4 and xenomia services work just fine. Please try and find the point in the latency test where the hang happens (it probably happens when calling a xenomai service, so, not sched_setscheduler), and then post the two disassemblies of this service implementation in libnative.so, the one compiled with 4.4, the other with 4.6. > > Cheers, -- Gilles. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 17:22 ` [Xenomai-core] " Gilles Chanteperdrix @ 2011-08-11 18:42 ` Daniele Nicolodi 2011-08-11 20:09 ` Gilles Chanteperdrix 0 siblings, 1 reply; 17+ messages in thread From: Daniele Nicolodi @ 2011-08-11 18:42 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai [-- Attachment #1: Type: text/plain, Size: 527 bytes --] On 11/08/11 19:22, Gilles Chanteperdrix wrote: > Please try and find the point in the latency test where the hang happens > (it probably happens when calling a xenomai service, so, not > sched_setscheduler), and then post the two disassemblies of this service > implementation in libnative.so, the one compiled with 4.4, the other > with 4.6. The latency test hangs in rt_task_create() attached the function disassemblies obtained with gcc-4.4 and gcc-4.6. Hope that this helps, those are Aramaic to me. Cheers, -- Daniele [-- Attachment #2: rt_task_create_gcc-4.4.dump --] [-- Type: text/plain, Size: 6027 bytes --] 00004f90 <rt_task_create>: 4f90: 55 push %ebp 4f91: 31 c0 xor %eax,%eax 4f93: 89 e5 mov %esp,%ebp 4f95: 57 push %edi 4f96: 56 push %esi 4f97: 53 push %ebx 4f98: 83 ec 7c sub $0x7c,%esp 4f9b: e8 17 d8 ff ff call 27b7 <__i686.get_pc_thunk.bx> 4fa0: 81 c3 24 17 00 00 add $0x1724,%ebx 4fa6: 53 push %ebx 4fa7: 89 c3 mov %eax,%ebx 4fa9: b8 2b 02 00 02 mov $0x200022b,%eax 4fae: cd 80 int $0x80 4fb0: 5b pop %ebx 4fb1: 8b 45 08 mov 0x8(%ebp),%eax 4fb4: 8d 75 a0 lea -0x60(%ebp),%esi 4fb7: 8b 7d 18 mov 0x18(%ebp),%edi -- 4ff9: 75 11 jne 500c <rt_task_create+0x7c> 4ffb: e8 98 d5 ff ff call 2598 <getpagesize@plt> 5000: 8d b8 00 40 00 00 lea 0x4000(%eax),%edi 5006: 89 bb cc 00 00 00 mov %edi,0xcc(%ebx) 500c: 8b 55 10 mov 0x10(%ebp),%edx 500f: 85 d2 test %edx,%edx 5011: 75 07 jne 501a <rt_task_create+0x8a> 5013: c7 45 90 00 80 00 00 movl $0x8000,-0x70(%ebp) 501a: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp) 5021: 00 5022: 89 34 24 mov %esi,(%esp) 5025: e8 ce d4 ff ff call 24f8 <pthread_attr_setinheritsched@plt> 502a: 8b 45 14 mov 0x14(%ebp),%eax 502d: c7 45 e4 00 00 00 00 movl $0x0,-0x1c(%ebp) 5034: 85 c0 test %eax,%eax 5036: 0f 8e bc 00 00 00 jle 50f8 <rt_task_create+0x168> 503c: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp) 5043: 00 5044: 89 34 24 mov %esi,(%esp) 5047: e8 9c d4 ff ff call 24e8 <pthread_attr_setschedpolicy@plt> 504c: 8b 45 14 mov 0x14(%ebp),%eax 504f: 89 45 e4 mov %eax,-0x1c(%ebp) 5052: 8d 45 e4 lea -0x1c(%ebp),%eax 5055: 89 44 24 04 mov %eax,0x4(%esp) 5059: 89 34 24 mov %esi,(%esp) 505c: e8 07 d5 ff ff call 2568 <pthread_attr_setschedparam@plt> 5061: 8b 45 90 mov -0x70(%ebp),%eax 5064: 39 f8 cmp %edi,%eax 5066: 73 02 jae 506a <rt_task_create+0xda> 5068: 89 f8 mov %edi,%eax 506a: 89 44 24 04 mov %eax,0x4(%esp) 506e: 89 34 24 mov %esi,(%esp) 5071: e8 82 d5 ff ff call 25f8 <pthread_attr_setstacksize@plt> 5076: 8b 7d 18 mov 0x18(%ebp),%edi 5079: 81 e7 00 04 00 00 and $0x400,%edi 507f: 89 7d 90 mov %edi,-0x70(%ebp) 5082: 74 5c je 50e0 <rt_task_create+0x150> 5084: 8d 45 c4 lea -0x3c(%ebp),%eax 5087: 89 44 24 0c mov %eax,0xc(%esp) 508b: 8d 83 cc e7 ff ff lea -0x1834(%ebx),%eax 5091: 89 44 24 08 mov %eax,0x8(%esp) 5095: 8d 45 e0 lea -0x20(%ebp),%eax 5098: 89 74 24 04 mov %esi,0x4(%esp) 509c: 89 04 24 mov %eax,(%esp) 509f: e8 e4 d5 ff ff call 2688 <__real_pthread_create@plt> 50a4: 85 c0 test %eax,%eax 50a6: 75 28 jne 50d0 <rt_task_create+0x140> 50a8: 8b 7d 94 mov -0x6c(%ebp),%edi 50ab: 53 push %ebx 50ac: 89 fb mov %edi,%ebx 50ae: b8 2b 02 00 01 mov $0x100022b,%eax 50b3: cd 80 int $0x80 50b5: 5b pop %ebx 50b6: 85 c0 test %eax,%eax 50b8: 89 c6 mov %eax,%esi 50ba: 74 07 je 50c3 <rt_task_create+0x133> 50bc: 8b 4d 90 mov -0x70(%ebp),%ecx 50bf: 85 c9 test %ecx,%ecx 50c1: 75 4d jne 5110 <rt_task_create+0x180> 50c3: 83 c4 7c add $0x7c,%esp 50c6: 89 f0 mov %esi,%eax 50c8: 5b pop %ebx 50c9: 5e pop %esi 50ca: 5f pop %edi 50cb: 5d pop %ebp 50cc: c3 ret 50cd: 8d 76 00 lea 0x0(%esi),%esi 50d0: 89 c6 mov %eax,%esi 50d2: 83 c4 7c add $0x7c,%esp 50d5: f7 de neg %esi 50d7: 89 f0 mov %esi,%eax 50d9: 5b pop %ebx 50da: 5e pop %esi 50db: 5f pop %edi 50dc: 5d pop %ebp 50dd: c3 ret -- 50f0: eb 92 jmp 5084 <rt_task_create+0xf4> 50f2: 8d b6 00 00 00 00 lea 0x0(%esi),%esi 50f8: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp) 50ff: 00 5100: 89 34 24 mov %esi,(%esp) 5103: e8 e0 d3 ff ff call 24e8 <pthread_attr_setschedpolicy@plt> 5108: e9 45 ff ff ff jmp 5052 <rt_task_create+0xc2> 510d: 8d 76 00 lea 0x0(%esi),%esi 5110: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp) 5117: 00 5118: 8b 45 e0 mov -0x20(%ebp),%eax 511b: 89 04 24 mov %eax,(%esp) 511e: e8 55 d5 ff ff call 2678 <pthread_join@plt> 5123: 83 c4 7c add $0x7c,%esp 5126: 89 f0 mov %esi,%eax 5128: 5b pop %ebx 5129: 5e pop %esi 512a: 5f pop %edi 512b: 5d pop %ebp 512c: c3 ret 512d: 90 nop 512e: 90 nop 512f: 90 nop [-- Attachment #3: rt_task_create_gcc-4.6.dump --] [-- Type: text/plain, Size: 5575 bytes --] 00004b60 <rt_task_create>: 4b60: 55 push %ebp 4b61: 31 c0 xor %eax,%eax 4b63: 57 push %edi 4b64: 56 push %esi 4b65: 53 push %ebx 4b66: 83 ec 7c sub $0x7c,%esp 4b69: 8b bc 24 9c 00 00 00 mov 0x9c(%esp),%edi 4b70: e8 82 dd ff ff call 28f7 <__i686.get_pc_thunk.bx> 4b75: 81 c3 c3 25 00 00 add $0x25c3,%ebx 4b7b: 53 push %ebx 4b7c: 89 c3 mov %eax,%ebx 4b7e: b8 2b 02 00 02 mov $0x200022b,%eax 4b83: cd 80 int $0x80 4b85: 5b pop %ebx 4b86: 8b 84 24 90 00 00 00 mov 0x90(%esp),%eax 4b8d: 8d 74 24 28 lea 0x28(%esp),%esi -- 4be2: 75 10 jne 4bf4 <rt_task_create+0x94> 4be4: e8 cf d9 ff ff call 25b8 <getpagesize@plt> 4be9: 05 00 40 00 00 add $0x4000,%eax 4bee: 89 83 cc 00 00 00 mov %eax,0xcc(%ebx) 4bf4: 8b 94 24 98 00 00 00 mov 0x98(%esp),%edx 4bfb: 85 d2 test %edx,%edx 4bfd: 75 05 jne 4c04 <rt_task_create+0xa4> 4bff: bd 00 80 00 00 mov $0x8000,%ebp 4c04: 39 c5 cmp %eax,%ebp 4c06: 73 02 jae 4c0a <rt_task_create+0xaa> 4c08: 89 c5 mov %eax,%ebp 4c0a: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp) 4c11: 00 4c12: 89 34 24 mov %esi,(%esp) 4c15: e8 fe d8 ff ff call 2518 <pthread_attr_setinheritsched@plt> 4c1a: 85 ff test %edi,%edi 4c1c: c7 44 24 68 00 00 00 movl $0x0,0x68(%esp) 4c23: 00 4c24: 0f 8e a6 00 00 00 jle 4cd0 <rt_task_create+0x170> 4c2a: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp) 4c31: 00 4c32: 89 34 24 mov %esi,(%esp) 4c35: e8 ce d8 ff ff call 2508 <pthread_attr_setschedpolicy@plt> 4c3a: 89 7c 24 68 mov %edi,0x68(%esp) 4c3e: 8d 44 24 68 lea 0x68(%esp),%eax 4c42: 89 44 24 04 mov %eax,0x4(%esp) 4c46: 89 34 24 mov %esi,(%esp) 4c49: e8 3a d9 ff ff call 2588 <pthread_attr_setschedparam@plt> 4c4e: 89 6c 24 04 mov %ebp,0x4(%esp) 4c52: 89 34 24 mov %esi,(%esp) 4c55: e8 be d9 ff ff call 2618 <pthread_attr_setstacksize@plt> 4c5a: 8b ac 24 a0 00 00 00 mov 0xa0(%esp),%ebp 4c61: 81 e5 00 04 00 00 and $0x400,%ebp 4c67: 74 4f je 4cb8 <rt_task_create+0x158> 4c69: 8d 44 24 4c lea 0x4c(%esp),%eax 4c6d: 89 44 24 0c mov %eax,0xc(%esp) 4c71: 8d 83 18 d9 ff ff lea -0x26e8(%ebx),%eax 4c77: 89 44 24 08 mov %eax,0x8(%esp) 4c7b: 8d 44 24 6c lea 0x6c(%esp),%eax 4c7f: 89 74 24 04 mov %esi,0x4(%esp) 4c83: 89 04 24 mov %eax,(%esp) 4c86: e8 1d da ff ff call 26a8 <__real_pthread_create@plt> 4c8b: 89 c6 mov %eax,%esi 4c8d: f7 de neg %esi 4c8f: 85 c0 test %eax,%eax 4c91: 75 19 jne 4cac <rt_task_create+0x14c> 4c93: 8b 7c 24 1c mov 0x1c(%esp),%edi 4c97: 53 push %ebx 4c98: 89 fb mov %edi,%ebx 4c9a: b8 2b 02 00 01 mov $0x100022b,%eax 4c9f: cd 80 int $0x80 4ca1: 5b pop %ebx 4ca2: 85 c0 test %eax,%eax 4ca4: 89 c6 mov %eax,%esi 4ca6: 74 04 je 4cac <rt_task_create+0x14c> 4ca8: 85 ed test %ebp,%ebp 4caa: 75 3c jne 4ce8 <rt_task_create+0x188> 4cac: 83 c4 7c add $0x7c,%esp 4caf: 89 f0 mov %esi,%eax 4cb1: 5b pop %ebx 4cb2: 5e pop %esi 4cb3: 5f pop %edi 4cb4: 5d pop %ebp 4cb5: c3 ret 4cb6: 66 90 xchg %ax,%ax 4cb8: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp) 4cbf: 00 4cc0: 89 34 24 mov %esi,(%esp) 4cc3: e8 20 da ff ff call 26e8 <pthread_attr_setdetachstate@plt> 4cc8: eb 9f jmp 4c69 <rt_task_create+0x109> 4cca: 8d b6 00 00 00 00 lea 0x0(%esi),%esi 4cd0: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp) 4cd7: 00 4cd8: 89 34 24 mov %esi,(%esp) 4cdb: e8 28 d8 ff ff call 2508 <pthread_attr_setschedpolicy@plt> 4ce0: e9 59 ff ff ff jmp 4c3e <rt_task_create+0xde> 4ce5: 8d 76 00 lea 0x0(%esi),%esi 4ce8: 8b 44 24 6c mov 0x6c(%esp),%eax 4cec: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp) 4cf3: 00 4cf4: 89 04 24 mov %eax,(%esp) 4cf7: e8 9c d9 ff ff call 2698 <pthread_join@plt> 4cfc: 83 c4 7c add $0x7c,%esp 4cff: 89 f0 mov %esi,%eax 4d01: 5b pop %ebx 4d02: 5e pop %esi 4d03: 5f pop %edi 4d04: 5d pop %ebp 4d05: c3 ret 4d06: 8d 76 00 lea 0x0(%esi),%esi 4d09: 8d bc 27 00 00 00 00 lea 0x0(%edi,%eiz,1),%edi ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai-core] gcc-4.6 issue 2011-08-11 18:42 ` Daniele Nicolodi @ 2011-08-11 20:09 ` Gilles Chanteperdrix 0 siblings, 0 replies; 17+ messages in thread From: Gilles Chanteperdrix @ 2011-08-11 20:09 UTC (permalink / raw) To: Daniele Nicolodi; +Cc: xenomai On 08/11/2011 08:42 PM, Daniele Nicolodi wrote: > On 11/08/11 19:22, Gilles Chanteperdrix wrote: > >> Please try and find the point in the latency test where the hang happens >> (it probably happens when calling a xenomai service, so, not >> sched_setscheduler), and then post the two disassemblies of this service >> implementation in libnative.so, the one compiled with 4.4, the other >> with 4.6. > > The latency test hangs in rt_task_create() attached the function > disassemblies obtained with gcc-4.4 and gcc-4.6. Hope that this helps, > those are Aramaic to me. The gcc 4.6 version is compiled with frame pointer disabled, whereas the 4.4 version is compiled with frame pointers. Enabling the -fomit-frame-pointer option with gcc 4.4 seems to cause issues as well. Could you test passing -fno-omit-frame-pointers in the CFLAGS with gcc 4.6 to see if it avoids the issue? Regards. -- Gilles. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-08-12 10:11 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-11 10:59 [Xenomai-core] gcc-4.6 issue Roland Stigge 2011-08-11 11:07 ` Gilles Chanteperdrix 2011-08-11 11:43 ` Daniele Nicolodi 2011-08-11 14:48 ` Daniele Nicolodi 2011-08-11 17:21 ` Roland Stigge 2011-08-11 17:31 ` Gilles Chanteperdrix 2011-08-11 19:34 ` Gilles Chanteperdrix 2011-08-11 20:52 ` Gilles Chanteperdrix 2011-08-11 23:18 ` Gilles Chanteperdrix 2011-08-12 8:18 ` Daniele Nicolodi 2011-08-12 8:46 ` Gilles Chanteperdrix 2011-08-12 10:08 ` Daniele Nicolodi 2011-08-12 10:11 ` Gilles Chanteperdrix 2011-08-12 8:20 ` [Xenomai-core] Bug#637425: " Roland Stigge 2011-08-11 17:22 ` [Xenomai-core] " Gilles Chanteperdrix 2011-08-11 18:42 ` Daniele Nicolodi 2011-08-11 20:09 ` Gilles Chanteperdrix
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.