Robert Diemer wrote:
Hello,
thank you for your answer, Steve. Unfortunatly your version from liHIL don't
work, too. There is the same error.
If I make a "strace gdbproxy msp430" (libHIL in 32bit version) I get the
following output:
...
open("/dev/parport0", O_RDWR) = 3
ioctl(3, PPCLAIM, 0xffffcf28) = 0
ioctl(3, PPDATADIR, 0xffffce34) = -1 EINVAL (Invalid argument)
dup(2) = 4
fcntl64(4, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
brk(0) = 0x8103000
brk(0x8124000) = 0x8124000
fstat64(0x4, 0xffffcc6c) = 0
...
On a 32bit computer the syscall "ioctl(3, PPDATADIR, 0xffffce34)" works, the
result is 0 and not -1.
And if I use a short test-program with libHIL, both in 64bit mode, it works
too.
Therefore I think the problem is the syscall.
Now, I don't know how to isolate the problem. I thought that the problem was
the conversion of the pointer in the ioctl-syscall to unsigned long.
Has anybody an idea?
Steve, can you tell me please which library you use with gdbproxy?
My ldd-output is
linux-gate.so.1 => (0xffffe000)
libHIL.so => /usr/local/msp430//lib32/libHIL.so (0x5556d000)
libc.so.6 => /lib32/libc.so.6 (0x55591000)
/lib/ld-linux.so.2 (0x55555000)
These are all 32bit libraries.
I guess the conversion of the unsigned long is the source of the
problem. However, it works out OK on other x86_64 machines. If it
didn't, 32 bit compatibility wouldn't work. ioctl calls are used by most
programs, though the ones to ppdev may be rare. My machine is running
Linux 2.6.13, but note that the Fedora versions of the kernels always
contain various patches. I used to run 2.6.12 on the same machine,
without problems.
My ldd output is:
linux-gate.so.1 => (0xffffe000)
libHIL.so => /usr/lib/libHIL.so (0xf7fc6000)
libc.so.6 => /lib/libc.so.6 (0x00a33000)
/lib/ld-linux.so.2 (0x00a15000)
Regards,
Steve
