From: Miles Lane <hidden> Date: 2003-08-03 01:23:30
CC drivers/input/evdev.o
drivers/input/evdev.c: In function `evdev_ioctl':
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
make[2]: *** [drivers/input/evdev.o] Error 1
Gnu C 3.3.1
Gnu make 3.80
util-linux 2.11z
mount 2.11x
e2fsprogs 1.32
pcmcia-cs 3.2.3
PPP 2.4.1
nfs-utils 1.0.5
Linux C Library 2.3.1
Dynamic linker (ldd) 2.3.1
Procps 3.1.6
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.0
GNU ld version 2.14 20030612
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_EVBUG=m
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Paul Mackerras <hidden> Date: 2003-08-03 11:23:33
Miles Lane writes:
CC drivers/input/evdev.o
drivers/input/evdev.c: In function `evdev_ioctl':
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
These errors are a consequence of the change I made to make get_user
work on 64-bit quantities. I can't actually see a way to have
get_user work when it's used the way it is here and also work on
64-bit quantities, without giving spurious warnings when used on
pointers.
Who was it that wanted 64-bit get_user? I think we are going to have
to make a separate get_user64().
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-08-03 11:31:24
On Sun, 2003-08-03 at 13:23, Paul Mackerras wrote:
Miles Lane writes:
quoted
CC drivers/input/evdev.o
drivers/input/evdev.c: In function `evdev_ioctl':
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
These errors are a consequence of the change I made to make get_user
work on 64-bit quantities. I can't actually see a way to have
get_user work when it's used the way it is here and also work on
64-bit quantities, without giving spurious warnings when used on
pointers.
Who was it that wanted 64-bit get_user? I think we are going to have
to make a separate get_user64().
No Paul, it's not your fault, if you look closely at evdev, that code
can't really work properly anyway.
I talked to Vojtech at OLS and he'll be fixing that to always pass
either an u32 or an int to userspace.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Franz Sirl <hidden> Date: 2003-08-04 08:49:47
At 13:31 03.08.2003, Benjamin Herrenschmidt wrote:
On Sun, 2003-08-03 at 13:23, Paul Mackerras wrote:
quoted
Miles Lane writes:
quoted
CC drivers/input/evdev.o
drivers/input/evdev.c: In function `evdev_ioctl':
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
drivers/input/evdev.c:243: error: invalid lvalue in asm statement
These errors are a consequence of the change I made to make get_user
work on 64-bit quantities. I can't actually see a way to have
get_user work when it's used the way it is here and also work on
64-bit quantities, without giving spurious warnings when used on
pointers.
Who was it that wanted 64-bit get_user? I think we are going to have
to make a separate get_user64().
No Paul, it's not your fault, if you look closely at evdev, that code
can't really work properly anyway.
Well, his patch to get_user exposed it, but the bug is really in the very
questionable use of the gcc extension to accept ?: expressions as lvalue,
see <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11564>
I talked to Vojtech at OLS and he'll be fixing that to always pass
either an u32 or an int to userspace.
I've sent him a patch too as a result of the above GCC PR.
Franz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-08-04 09:42:21
On Mon, 2003-08-04 at 10:49, Franz Sirl wrote:
quoted
No Paul, it's not your fault, if you look closely at evdev, that code
can't really work properly anyway.
Well, his patch to get_user exposed it, but the bug is really in the very
questionable use of the gcc extension to accept ?: expressions as lvalue,
see <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11564>
quoted
I talked to Vojtech at OLS and he'll be fixing that to always pass
either an u32 or an int to userspace.
I've sent him a patch too as a result of the above GCC PR.
It's still totally wrong to access userland with a variable sized
data since my understanding is that userland doesn't know what size
the kernel will use for access here, thus it works for little endian
but not big endian (well... afaik).
Vojtech and I agreed that this should be changed into uniform use
of a single sized type (u32 or int) that gets only converted in
the kernel.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Paul Mackerras <hidden> Date: 2003-08-04 11:24:54
Benjamin Herrenschmidt writes:
It's still totally wrong to access userland with a variable sized
data since my understanding is that userland doesn't know what size
the kernel will use for access here, thus it works for little endian
but not big endian (well... afaik).
The userland data isn't variable-sized; it's an int, and it is
accessed as an int because the pointer given to get_user is int *.
The problem is (as Franz pointed out) the use of (a? b: c) as an
lvalue.
Incidentally there is a bug in the INPUT_KEYCODE macro: the second
(dev->keycodesize == 1) should be == 2 instead (the condition for the
u16 case).
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/