Xen devel - Nov 2007 - [PATCH] x86: usercopy assembly constraints

Besides only being correct this way, this helps work around a gcc 4.3
issue.
At the same time, add some white space, re-order the inputs, and remove
a bogus cast.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

Index: 2007-11-13/xen/arch/x86/usercopy.c
==================================================================---
2007-11-13.orig/xen/arch/x86/usercopy.c	2007-11-13 15:36:25.000000000 +0100
+++ 2007-11-13/xen/arch/x86/usercopy.c	2007-11-13 15:37:36.000000000 +0100
@@ -41,10 +41,10 @@ unsigned long __copy_to_user_ll(void __u
 		"	"__FIXUP_WORD" 0b,3b\n"
 		"	"__FIXUP_WORD" 1b,2b\n"
 		".previous"
-		: "=&c"(__n), "=&D" (__d0), "=&S"
(__d1), "=r"(__d2)
-		: "3"(__n), "0"(__n), "1"(to),
"2"(from)
+		: "=&c" (__n), "=&D" (__d0), "=&S"
(__d1), "=&r" (__d2)
+		: "0" (__n), "1" (to), "2" (from),
"3" (__n)
 		: "memory");
-	return (unsigned)__n;
+	return __n;
 }
 
 unsigned long
@@ -85,10 +85,10 @@ __copy_from_user_ll(void *to, const void
 		"	"__FIXUP_WORD" 0b,3b\n"
 		"	"__FIXUP_WORD" 1b,6b\n"
 		".previous"
-		: "=&c"(__n), "=&D" (__d0), "=&S"
(__d1), "=r"(__d2)
-		: "3"(__n), "0"(__n), "1"(to),
"2"(from)
+		: "=&c" (__n), "=&D" (__d0), "=&S"
(__d1), "=&r" (__d2)
+		: "0" (__n), "1" (to), "2" (from),
"3" (__n)
 		: "memory");
-	return (unsigned)__n;
+	return __n;
 }
 
 /**




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 13/11/07 16:02, "Jan Beulich" <jbeulich@novell.com> wrote:
> Besides only being correct this way, this helps work around a gcc 4.3
> issue.
> At the same time, add some white space, re-order the inputs, and remove
> a bogus cast.
What''s the bug? Does some gcc allocate the 4th output parameter into
one of
the other used registers (cx,si,di) if we don''t use
''=&''?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 13/11/07 20:20, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>
wrote:
> On 13/11/07 16:02, "Jan Beulich" <jbeulich@novell.com>
wrote:
> 
>> Besides only being correct this way, this helps work around a gcc 4.3
>> issue.
>> At the same time, add some white space, re-order the inputs, and remove
>> a bogus cast.
> 
> What''s the bug? Does some gcc allocate the 4th output parameter
into one of
> the other used registers (cx,si,di) if we don''t use
''=&''?
If this is the case, it sounds to me like a gcc bug (allocating two outputs
into the same register) and it could potentially hit on a number of our
other asm statements I''m pretty sure.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 13.11.07 21:20
>>>
>On 13/11/07 16:02, "Jan Beulich" <jbeulich@novell.com>
wrote:
>
>> Besides only being correct this way, this helps work around a gcc 4.3
>> issue.
>> At the same time, add some white space, re-order the inputs, and remove
>> a bogus cast.
>
>What''s the bug? Does some gcc allocate the 4th output parameter
into one of
>the other used registers (cx,si,di) if we don''t use
''=&''?
No, the effect is an ''impossible constraint'' error, so
there''s not much reason
to be afraid I think. But as said, the constraint was wrong.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 14/11/07 07:37, "Jan Beulich" <jbeulich@novell.com> wrote:
>> What''s the bug? Does some gcc allocate the 4th output
parameter into one of
>> the other used registers (cx,si,di) if we don''t use
''=&''?
> 
> No, the effect is an ''impossible constraint'' error, so
there''s not much reason
> to be afraid I think. But as said, the constraint was wrong.
I thought ''&'' was an extra constraint, so I''m
surprised it could fix an
''impossible constraint'' problem. But anyway, yes, the code is
saner and more
consistent with your patch.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel