[Xenomai-core] gcc-4.6 issue

[Xenomai-core] gcc-4.6 issue

[Roland Stigge]

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

Re: [Xenomai-core] gcc-4.6 issue

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] gcc-4.6 issue

[Daniele Nicolodi]

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

Re: [Xenomai-core] gcc-4.6 issue

[Daniele Nicolodi]

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

Re: [Xenomai-core] gcc-4.6 issue

[Roland Stigge]

[-- 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

Re: [Xenomai-core] gcc-4.6 issue

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] gcc-4.6 issue

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] gcc-4.6 issue

[Daniele Nicolodi]

[-- 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

Re: [Xenomai-core] gcc-4.6 issue

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] gcc-4.6 issue

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] gcc-4.6 issue

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] gcc-4.6 issue

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] gcc-4.6 issue

[Daniele Nicolodi]

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

Re: [Xenomai-core] Bug#637425: gcc-4.6 issue

[Roland Stigge]

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

Re: [Xenomai-core] gcc-4.6 issue

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] gcc-4.6 issue

[Daniele Nicolodi]

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

Re: [Xenomai-core] gcc-4.6 issue

[Gilles Chanteperdrix]

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.