[Fwd: [Qemu-devel] RFC: linux user problems]

[J. Mayer]

Following my previous message, I did a patch that makes syscalls take
target_long/target_ulong argument and return target_long value instead
of long/unsigned long.
I also included the #ifdef protection for do_socketcall and do_ipc to
avoid compilation warnings.
And I also converted the fd given to do_ioctl to be an int.

In addition to my previous remarks, I noticed some other things while
reading the code:
- the do_msgctl function seems very strange to me. It looks like half of
the code is missing in the switch...
- do_ipc directly uses pointers from the emulated environment without
using lock_user related functions like it seems to be done everywhere
else.
- there are at least two problems in IPCOP_shmat:
 * the returned address could not fit in the target address space when
emulating a 32 bits
  target on a 64 bits host
* the returned address is always casted into a 32 bits value. I changed
this to be target_ulong.
- I also noticed some suspicious warnings (cast between pointer and
integer of different size) that may hide other problems:
* target_to_host_cmsg:567
* host_to_target_cmsg:612
* do_ipc:1609
* do_ipc: 1621
* do_ipc: 1645
* do_ipc: 1655
* do_ipc: 1677 (multiple times)
* do_ipc: 1687
* do_ipc: 1711
* do_syscall:2686
* do_syscall: 3903
* do_syscall: 4671

May someone take a look at my patch and say if it seems reasonable to
include this in the repository ?
I did not notice any regression, launching 32 bits programs on a 64 bits
host, but I did not do any unitary tests to trigger specific bugs, just
launched command lines programs like bash, make, ... and used them. Then
other looks to the patch would be welcome !

-------- Forwarded Message --------
> From: J. Mayer <address@hidden>
> Reply-To: address@hidden
> To: address@hidden
> Subject: [Qemu-devel] RFC: linux user problems
> Date: Mon, 17 Sep 2007 23:04:00 +0200
> 
> It seems to me that there are many problems in linux-user/syscall.c
> - minor fixes, just to avoid compilation warnings:
> do_socketcall should be inside a #ifdef TARGET_NR_socketcall block
> do_ipc should be inside a #ifdef TARGET_NR_ipc block
> - problems for 64 bits targets:
> it seems that do_syscall and child functions should take target_long /
> target_ulong arguments instead of long / unsigned long. This would make
> a chance for 64 bits targets to be ran on 32 bits hosts (even if, yes,
> there would also be other problems to fix elsewhere...).
> - ipc specific problems:
> some structure used for IPC definitions have been merged. They used to
> be target specific and now are generic. But it seems to me that many
> mistakes have been done here, while comparing with the PowerPC 64 target
> definition, which has not been merged:
> struct target_ipc_perm {
>       int     __key;
>       unsigned short  uid;
>       unsigned short  gid;
>       unsigned short  cuid;
>       unsigned short  cgid;
>       unsigned short  mode;
>       unsigned short  seq;
> };
> in PowerPC 64 becomes:
> struct target_ipc_perm
> {
>     target_long __key;
>     target_ulong uid;
>     target_ulong gid;
>     target_ulong cuid;
>     target_ulong cgid;
>     unsigned short int mode;
>     unsigned short int __pad1;
>     unsigned short int __seq;
>     unsigned short int __pad2;
>     target_ulong __unused1;
>     target_ulong __unused2;
> };
> in generic code.
> Problems are, imho:
> int is not the same size than target_long on 64 bits targets.
> unsigned short is never the same size than target_ulong (am I wrong ?)
> there should be a target_short definition: are we sure short on the host
> is always the same size than target_short ?
> I also don't understand the padding logic here (does the original
> target_ipc_perm structure relies on alignments generated by the
> compiler ?).
> I found the same kind of problems for the target_msqid_ds and
> target_msgbuf structure.
> I may be wrong, but it seems to me that those problems are not PowerPC
> 64 specific and that there are some serious bugs to be fixed here. Can
> someone confirm this or tell me what I missed ?
> 
> Regards.
> 
-- 
J. Mayer <address@hidden>
Never organized

syscall.diff
Description: Text Data