Displaying 5 results from an estimated 5 matches for "__pu_val".
2009 Jan 24
5
[LLVMdev] inline asm semantics: output constraint width smaller than input
...(size, x, ptr, __ret_pu) \
@@ -239,11 +239,13 @@ extern void __put_user_8(void);
*/
#define put_user(x, ptr) \
({ \
- int __ret_pu; \
+ __typeof__(*(ptr)) __ret_pu; \
__typeof__(*(ptr)) __pu_val; \
__chk_user_ptr(ptr); \
might_fault(); \
__pu_val = x; \
+ /* return value is 0 or -EFAULT, both fit in 1 byte, and \
+ * are sign-extendable to int */ \
switch (sizeof(*(pt...
2009 Jan 24
1
[LLVMdev] inline asm semantics: output constraint width smaller than input
...e?
>
It would fail at compile time, with an error message that you can't cast
aggregates to ints, so my patch is not good.
> We'll fall into this branch in that case:
>
> default: \
> __put_user_x(X, __pu_val, ptr, __ret_pu); \
> break; \
>
> and __ret_pu has a nonsensical type in that case.
>
That branch is a call to a non-existent function __put_user_X, and
should give error at link time, right?
In the new patch below I use...
2009 Jan 24
0
[LLVMdev] inline asm semantics: output constraint width smaller than input
...\
This does not look right. We can sometimes have put_user() of non-integer
types (say structures). How does the (int)__ret_pu cast work in that case?
We'll fall into this branch in that case:
default: \
__put_user_x(X, __pu_val, ptr, __ret_pu); \
break; \
and __ret_pu has a nonsensical type in that case.
> __typeof__(*(ptr)) __pu_val; \
> __chk_user_ptr(ptr); \
> might_fault();...
2009 Jan 27
0
[LLVMdev] inline asm semantics: output constraint width smaller than input
...ll __put_user_" #size : "=a" (__ret_pu) \
:"0" ((typeof(*(ptr)))(x)), "c" (ptr) : "ebx")
#define put_user(x, ptr) \
({ \
int __ret_pu; \
__typeof__(*(ptr)) __pu_val; \
__chk_user_ptr(ptr); \
__pu_val = x; \
switch (sizeof(*(ptr))) { \
case 1: \
__put_user_x(1, __pu_val, ptr, __ret_pu); \
break; \
case...
2009 Jan 27
3
[LLVMdev] inline asm semantics: output constraint width smaller than input
On Tuesday 27 January 2009 20:56:30 Mike Stump wrote:
> On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote:
> > one thing that seems to be clear to everyone except me is... what
> > are the
> > semantics supposed to be?
>
> I don't know of any other semantic other than, if they are supposed to
> be in the same register, then they have to be in the same register.