Re: [Xenomai-core] gcc-4.6 issue
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
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 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@,$(testdir), $ $@ -EXTRA_DIST = $(test_SCRIPTS) +EXTRA_DIST = $(test_SCRIPTS) xeno-test.in ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
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 4f90 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 7csub$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 08mov0x8(%ebp),%eax 4fb4: 8d 75 a0lea-0x60(%ebp),%esi 4fb7: 8b 7d 18mov0x18(%ebp),%edi -- 4ff9: 75 11 jne500c rt_task_create+0x7c 4ffb: e8 98 d5 ff ff call 2598 getpagesize@plt 5000: 8d b8 00 40 00 00 lea0x4000(%eax),%edi 5006: 89 bb cc 00 00 00 mov%edi,0xcc(%ebx) 500c: 8b 55 10mov0x10(%ebp),%edx 500f: 85 d2 test %edx,%edx 5011: 75 07 jne501a rt_task_create+0x8a 5013: c7 45 90 00 80 00 00movl $0x8000,-0x70(%ebp) 501a: c7 44 24 04 01 00 00movl $0x1,0x4(%esp) 5021: 00 5022: 89 34 24mov%esi,(%esp) 5025: e8 ce d4 ff ff call 24f8 pthread_attr_setinheritsched@plt 502a: 8b 45 14mov0x14(%ebp),%eax 502d: c7 45 e4 00 00 00 00movl $0x0,-0x1c(%ebp) 5034: 85 c0 test %eax,%eax 5036: 0f 8e bc 00 00 00 jle50f8 rt_task_create+0x168 503c: c7 44 24 04 01 00 00movl $0x1,0x4(%esp) 5043: 00 5044: 89 34 24mov%esi,(%esp) 5047: e8 9c d4 ff ff call 24e8 pthread_attr_setschedpolicy@plt 504c: 8b 45 14mov0x14(%ebp),%eax 504f: 89 45 e4mov%eax,-0x1c(%ebp) 5052: 8d 45 e4lea-0x1c(%ebp),%eax 5055: 89 44 24 04 mov%eax,0x4(%esp) 5059: 89 34 24mov%esi,(%esp) 505c: e8 07 d5 ff ff call 2568 pthread_attr_setschedparam@plt 5061: 8b 45 90mov-0x70(%ebp),%eax 5064: 39 f8 cmp%edi,%eax 5066: 73 02 jae506a rt_task_create+0xda 5068: 89 f8 mov%edi,%eax 506a: 89 44 24 04 mov%eax,0x4(%esp) 506e: 89 34 24mov%esi,(%esp) 5071: e8 82 d5 ff ff call 25f8 pthread_attr_setstacksize@plt 5076: 8b 7d 18mov0x18(%ebp),%edi 5079: 81 e7 00 04 00 00 and$0x400,%edi 507f: 89 7d 90mov%edi,-0x70(%ebp) 5082: 74 5c je 50e0 rt_task_create+0x150 5084: 8d 45 c4lea-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 e0lea-0x20(%ebp),%eax 5098: 89 74 24 04 mov%esi,0x4(%esp) 509c: 89 04 24mov%eax,(%esp) 509f: e8 e4 d5 ff ff call 2688 __real_pthread_create@plt 50a4: 85 c0 test %eax,%eax 50a6: 75 28 jne50d0 rt_task_create+0x140 50a8: 8b 7d 94mov-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
Re: [Xenomai-core] gcc-4.6 issue
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
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 fcmov%eax,-0x4(%ebp) Move the result from eax to temporary space on stack. 19: 8b 45 08mov0x8(%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 fcmov-0x4(%ebp),%eax Reload the syscall number from its temporary storage to eax. 22: 65 ff 15 10 00 00 00call *%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 mov0x18(%esp),%eax 4e4c: 53 push %ebx 4e4d: 89 c3 mov%eax,%ebx 4e4f: 8b 44 24 0c mov0xc(%esp),%eax 4e53: 65 ff 15 10 00 00 00call *%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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
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 fcmov%eax,-0x4(%ebp) Move the result from eax to temporary space on stack. 19: 8b 45 08mov0x8(%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 fcmov-0x4(%ebp),%eax Reload the syscall number from its temporary storage to eax. 22: 65 ff 15 10 00 00 00call *%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 mov0x18(%esp),%eax 4e4c: 53 push %ebx 4e4d: 89 c3 mov%eax,%ebx 4e4f: 8b 44 24 0c mov0xc(%esp),%eax 4e53: 65 ff 15 10 00 00 00call *%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) \ + :
