Skip to contentSkip to conversation

x86: usercopy assembly constraints

PATCH In review Jan Beulich 2 participants 5 messages Nov 13, 2007 – Nov 14, 2007

lore
Share & tools
lore

Jan Beulich

author
#0 lore raw

PATCH 1/1 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 <[email protected]>
xen/arch/x86/usercopy.c +6 -6
Index: 2007-11-13/xen/arch/x86/usercopy.c
===================================================================
@@ -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;
 }
 
 /**
#1 lore raw
Quoted 4 lines · Jan Beulich

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

#2 lore raw
Quoted 9 lines · Keir Fraser
Quoted 4 lines · Jan Beulich

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

author
#3 lore raw
In reply to Keir Fraser
Quoted 10 lines
Quoted 1 line
Quoted 1 line

Keir Fraser <[email protected]> 13.11.07 21:20 >>>

Quoted 4 lines · Jan Beulich

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

#4 lore raw
Quoted 5 lines · Jan Beulich
Quoted 2 lines

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