[Qemu-devel] qemu/target-ppc op.c op_helper.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/03/21 08:21:02 Modified files: target-ppc : op.c op_helper.h Log message: Fix compilation on 32 bits hosts (pb reported by Thiemo Seufer) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.26&r2=1.27 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.h?cvsroot=qemu&r1=1.4&r2=1.5 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-cvs-2007-3-21 compile error
make[1]: Entering directory `/home/hys545/qemu/ppc64-softmmu' gcc32 -g -o qemu-system-ppc64 vl.o osdep.o readline.o monitor.o pci.o console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o scsi-disk.o cdrom.o lsi53c895a.o usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o ne2000.o rtl8139.o pcnet.o ppc.o ide.o pckbd.o ps2.o vga.o sb16.o es1370.o dma.o audio.o noaudio.o wavaudio.o sdlaudio.o ossaudio.o wavcapture.o mc146818rtc.o serial.o i8259.o i8254.o fdc.o m48t59.o ppc_prep.o ppc_chrp.o cuda.o adb.o openpic.o heathrow_pic.o mixeng.o grackle_pci.o prep_pci.o unin_pci.o gdbstub.o sdl.o x_keymap.o vnc.o slirp/cksum.o slirp/if.o slirp/ip_icmp.o slirp/ip_input.o slirp/ip_output.o slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o slirp/socket.o slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o slirp/tcp_timer.o slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o libqemu.a -lm -lz -L/usr/lib -lSDL -! lpthread -lrt -lutil libqemu.a(translate-op.o): In function `dyngen_code': /home/hys545/qemu/ppc64-softmmu/op.h:4857: undefined reference to `cntlzw' /home/hys545/qemu/ppc64-softmmu/op.h:4858: undefined reference to `cntlzw' libqemu.a(op.o): In function `_do_cntlzd': /home/hys545/qemu/target-ppc/op_helper.h:319: undefined reference to `cntlzw' /home/hys545/qemu/target-ppc/op_helper.h:321: undefined reference to `cntlzw' - Your Life on the Net DreamWiz Free Mail @ http://www.dreamwiz.com/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Documentation bug in QEMU/KQEMU
On Wednesday, March 21, 2007, 7:13:16, James Jacobs wrote: > Suggested fix: support Win98SE. Is there a good technical reason why it > can't be supported? System obsolescence? Completely different kernel driver model compared to NT? > * Also, \\.\kqemu is not a legal pathname under any version of Windows. It's perfectly legal in the object manager namespace (which doesn't exist on non-NT Windows). -- < Jernej Simončič ><><><><>< http://deepthought.ena.si/ > People are always available for work in the past tense. -- Zymurgy's Law of Volunteer Labour ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips mips-defs.h translate.c transl...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/03/21 11:04:42 Modified files: target-mips: mips-defs.h translate.c translate_init.c Log message: Move mips CPU specific initialization to translate_init.c. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.39&r2=1.40 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemu&r1=1.1&r2=1.2 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Documentation bug in QEMU/KQEMU
Hi, On Wed, 21 Mar 2007, James Jacobs wrote: > It is not mentioned that KQEMU is incompatible with Win98SE. > > Suggested fix: support Win98SE. Patches, please? Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Documentation bug in QEMU/KQEMU
On 21 Mar 2007, at 06:13, James Jacobs wrote: It is not mentioned that KQEMU is incompatible with Win98SE. It is also not mentioned that it is incompatible with Linux 0.1. However, if you make a closed world assumption (things which are not stated to be true are false), this is easy to infer: "KQEMU is supported on x86 or x86_64 Linux 2.4 or 2.6 hosts. Experimental versions are available for FreeBSD and Windows NT/ 2000/2003/XP." -- http://fabrice.bellard.free.fr/qemu/kqemu-doc.html#SEC1 * Also, \\.\kqemu is not a legal pathname under any version of Windows. If I remember correctly, this is roughly NT-flavour Windows' version of /dev, and you can find such curiosities as \\.\PhysicalDrive0 under there. MSDN probably has more details, if you can find them. Phil ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH][SPARC] Fix branch conditions
Hi,
I have noticed that the condition table in target-sparc/translate.c is
wrong wrt ba and bnr, they are reversed. The emulation is still correct
as they are currently not used (do_branch() has two cases to handle
them). However I think it is a good idea to fix that, as they may be
used at some point.
Bye,
Aurelien
Index: target-sparc/translate.c
===
RCS file: /sources/qemu/qemu/target-sparc/translate.c,v
retrieving revision 1.34
diff -u -d -p -r1.34 translate.c
--- target-sparc/translate.c23 Oct 2006 21:37:34 - 1.34
+++ target-sparc/translate.c21 Mar 2007 10:47:35 -
@@ -681,7 +681,7 @@ static inline void gen_mov_pc_npc(DisasC
static GenOpFunc * const gen_cond[2][16] = {
{
- gen_op_eval_ba,
+ gen_op_eval_bn,
gen_op_eval_be,
gen_op_eval_ble,
gen_op_eval_bl,
@@ -689,7 +689,7 @@ static GenOpFunc * const gen_cond[2][16]
gen_op_eval_bcs,
gen_op_eval_bneg,
gen_op_eval_bvs,
- gen_op_eval_bn,
+ gen_op_eval_ba,
gen_op_eval_bne,
gen_op_eval_bg,
gen_op_eval_bge,
@@ -722,7 +722,7 @@ static GenOpFunc * const gen_cond[2][16]
static GenOpFunc * const gen_fcond[4][16] = {
{
- gen_op_eval_ba,
+ gen_op_eval_bn,
gen_op_eval_fbne,
gen_op_eval_fblg,
gen_op_eval_fbul,
@@ -730,7 +730,7 @@ static GenOpFunc * const gen_fcond[4][16
gen_op_eval_fbug,
gen_op_eval_fbg,
gen_op_eval_fbu,
- gen_op_eval_bn,
+ gen_op_eval_ba,
gen_op_eval_fbe,
gen_op_eval_fbue,
gen_op_eval_fbge,
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [SPARC] Branch condition problems
Hi all, I have noticed that the branches have some problem on the sparc target in very rare conditions. This happens when a store double instruction (std) is used in the delay slot, as in the following test: tst %g0 bne 9b5d8 std %o2, [ %o1 ] Inserting a nop between bne and std "fixes" the problem. tst %g0 sets the zero flag, so that the branch should never be taked. It happens however that it is sometimes taken. This seems to be due to the fact that T2 holds the result of the condition, and std replace T2 with another value. flush_T2() is called before altering T2, but it does not seems to work. I am currently stuck at that point, I hope somebody who has better understanding of the branch code on Sparc could fix that. Thanks, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On Wed, 21 Mar 2007, Kirill A. Shutemov wrote: Primarily, I also thought that problem is in padding, because, without the patch F_GETLK, on 32-bit target recognises as F_GETLK64 on 64-bit host. It's happen because on 64-bit host and 32-bit target F_GETLK == F_GETLK64 == TARGET_F_GETLK. So if you're using qemu-arm on 64-bit host and a target eabi program calls fcntl(fd,F_GETLK,...), target_eabi_flock64 will be used by mistake. Disabling padding can helps in some trivial cases to pass pseudo-correct args to fcntl. I guess this part of patch wrong. Stuart, am I right? Yes, this is a good summary of the trap I initially fell into. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On Tue, 20 Mar 2007, Paul Brook wrote: Now that the dust has settled, I see where the change is probably a no-op anyway. A quick little test program indicates that on x86_64, l_start will have an offset of 8 wether the structure is packed or not, and wether the __pad member is present or not. The unsigned long long is always going to be aligned to a 8 byte boundary. The __pad member is essential. Your logic is wrong is two ways: a) The struct is packed. This overrides normal alignment and ensures the structure contains no padding. And in this case, it does remove some tail padding at the end of the structure. b) long long has whatever alignment the host feels like giving it. There's no guarantee it's going to be 8 byte aligned. No there isn't. This was just an observation of what occurs when building a simple test case on x86_64. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
On Mon, Mar 19, 2007 at 10:16:13PM +, Philip Boulain wrote: > On 19 Mar 2007, at 20:23, Derek Fawcus wrote: > > There was just a discussion relating to this on the darwin-kernel > > list, > > you may wish to review the archive. > > > > (The thread starts at http://lists.apple.com/archives/Darwin-kernel/ > > 2007/Mar/msg00010.html). > > Thanks; looking at this post, I'm probably barking up the right tree: > > http://lists.apple.com/archives/Darwin-kernel/2007/Mar/msg00031.html Well, they seemed to be suggesting that the kernel importing and locking the user space memory was a bit dodgy, and that the kernel should export memory to user space. Or maybe that only really applies inthe case of devices... DF ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
On 21 Mar 2007, at 15:39, Derek Fawcus wrote: Well, they seemed to be suggesting that the kernel importing and locking the user space memory was a bit dodgy, and that the kernel should export memory to user space. Or maybe that only really applies in the case of devices... Yes. It's perfectly valid to point out that this is usually a bad thing to do, but to refuse to help on those grounds is---well, unhelpful. Sometimes, you have no choice but to do something which is normally bizzare. (What I /don't/ get is why Bhavesh didn't explain the 'bizzare' circumstances, given that that thread appears to be post-GPL-KQEMU.) I can see why this appears to be a bad thing, but it's also how KQEMU works, and I'm guessing that /that/ is for good reasons, even if they're good reasons on some other platform it supports. (One that comes to mind is that you /probably/ don't want to ask for 4GB of kernel-allocated memory in order to run a VM with 4GB of RAM.) AFAICT, the worst /effect/ of this is that a userland application could cause the kernel to either wire down so much memory that it can't swap things in, or run out of kernel address space, and I would expect those risks to affect other platforms too---in other words, you could probably crash the system from a userland application with access to the /dev/kqemu device. I /don't/ see any reason why it should be "dodgy" in the unpleasant-to-debug--side-effects sense; hopefully because no such reason exists. :) Phil ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] [SPARC] Branch condition problems
I have noticed that the branches have some problem on the sparc target in very rare conditions. This happens when a store double instruction (std) is used in the delay slot, as in the following test: tst %g0 bne 9b5d8 std %o2, [ %o1 ] Inserting a nop between bne and std "fixes" the problem. tst %g0 sets the zero flag, so that the branch should never be taked. It happens however that it is sometimes taken. This seems to be due to the fact that T2 holds the result of the condition, and std replace T2 with another value. flush_T2() is called before altering T2, but it does not seems to work. I am currently stuck at that point, I hope somebody who has better understanding of the branch code on Sparc could fix that. Nice analysis, thanks. Flush_T2 is probably a misnomer. One solution could be adding a new field to CPU structure for std's (and stda's) use, so that T2 does not need to be used. _ Interest Rates near 39yr lows! $430,000 Mortgage for $1,399/mo - Calculate new payment http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-18466&moid=7581 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] [PATCH][SPARC] Fix branch conditions
I have noticed that the condition table in target-sparc/translate.c is wrong wrt ba and bnr, they are reversed. The emulation is still correct as they are currently not used (do_branch() has two cases to handle them). However I think it is a good idea to fix that, as they may be used at some point. You're right. The same problem exists with FPU branches and Sparc64 as well. _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [SPARC] Branch condition problems
On Wed, Mar 21, 2007 at 07:42:20PM +0100, Blue Swirl wrote: > >I have noticed that the branches have some problem on the sparc target > >in very rare conditions. This happens when a store double instruction > >(std) is used in the delay slot, as in the following test: > > > > tst %g0 > > bne 9b5d8 > > std %o2, [ %o1 ] > > > >Inserting a nop between bne and std "fixes" the problem. > > > >tst %g0 sets the zero flag, so that the branch should never be taked. It > >happens however that it is sometimes taken. This seems to be due to the > >fact that T2 holds the result of the condition, and std replace T2 with > >another value. flush_T2() is called before altering T2, but it does not > >seems to work. > > > >I am currently stuck at that point, I hope somebody who has better > >understanding of the branch code on Sparc could fix that. > > Nice analysis, thanks. Flush_T2 is probably a misnomer. One solution could You basically says that flush_T2() should not be used in this case, right? > be adding a new field to CPU structure for std's (and stda's) use, so that > T2 does not need to be used. >From my tests, it seems that std in a delayed branch slot occurs a hundred of time during a boot, so not a lot. Adding a new field to the CPU structure would probably decrease the performances (except on hosts with a lot of registers). Therefore I am proposing something like that (currently for std only): --- target-sparc/translate.c.orig 2007-03-21 02:59:49.0 +0100 +++ target-sparc/translate.c2007-03-21 20:23:21.0 +0100 @@ -2454,9 +2454,11 @@ gen_op_ldst(sth); break; case 0x7: -flush_T2(dc); - gen_movl_reg_T2(rd + 1); - gen_op_ldst(std); + gen_op_ldst(st); + gen_op_movl_T1_im(4); + gen_op_add_T1_T0(); + gen_movl_reg_T1(rd + 1); + gen_op_ldst(st); break; #if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) case 0x14: What do you thing? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [SPARC] Branch condition problems
From my tests, it seems that std in a delayed branch slot occurs a hundred of time during a boot, so not a lot. Adding a new field to the CPU structure would probably decrease the performances (except on hosts with a lot of registers). Therefore I am proposing something like that (currently for std only): Can you test if this works instead? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ std.diff.bz2 Description: application/bzip ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [SPARC] Branch condition problems
Blue Swirl a écrit : >>From my tests, it seems that std in a delayed branch slot occurs a >> hundred of time during a boot, so not a lot. Adding a new field to the >> CPU structure would probably decrease the performances (except on >> hosts with a lot of registers). Therefore I am proposing something like >> that (currently for std only): > > Can you test if this works instead? > The first hunk works well, and is indeed better than my patch. The second hunk applies, but does not compile. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [SPARC] Branch condition problems
On Wed, Mar 21, 2007 at 09:34:46PM +0100, Aurelien Jarno wrote: > Blue Swirl a écrit : > >>From my tests, it seems that std in a delayed branch slot occurs a > >> hundred of time during a boot, so not a lot. Adding a new field to the > >> CPU structure would probably decrease the performances (except on > >> hosts with a lot of registers). Therefore I am proposing something like > >> that (currently for std only): > > > > Can you test if this works instead? > > > > The first hunk works well, and is indeed better than my patch. The > second hunk applies, but does not compile. > The patch below (that includes the first hunk of your patch) also fixes stda. There is probably a smarter way to do that for the second hunk, but that imply more changes. Index: target-sparc/translate.c === RCS file: /sources/qemu/qemu/target-sparc/translate.c,v retrieving revision 1.34 diff -u -d -p -r1.34 translate.c --- target-sparc/translate.c23 Oct 2006 21:37:34 - 1.34 +++ target-sparc/translate.c21 Mar 2007 21:23:18 - @@ -2454,8 +2454,8 @@ static void disas_sparc_insn(DisasContex gen_op_ldst(sth); break; case 0x7: -flush_T2(dc); - gen_movl_reg_T2(rd + 1); +gen_op_ldst(st); +gen_movl_reg_T1(rd + 1); gen_op_ldst(std); break; #if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) @@ -2485,9 +2485,11 @@ static void disas_sparc_insn(DisasContex if (!supervisor(dc)) goto priv_insn; #endif -flush_T2(dc); - gen_movl_reg_T2(rd + 1); - gen_op_stda(insn, 0, 8, 0); + gen_op_stda(insn, 0, 4, 0); + gen_op_movl_T1_im(4); + gen_op_add_T1_T0(); + gen_movl_reg_T1(rd + 1); + gen_op_stda(insn, 0, 4, 0); break; #endif #ifdef TARGET_SPARC64 -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] message queue completion
Like the semaphore patch a couple of days ago, this patch completes the
implementation of the message queue syscalls. With this patch, most
of the message queue tests in LTP now pass in the guest. The remaining
ones will require fixes in other syscall to fix, or at least eliminate
the noise to identify any lingering issues.
This was testing using ARM guest on a x86_64 host.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 2007-03-21 20:32:30.0 -0400
+++ qemu/linux-user/syscall.c 2007-03-21 21:07:50.0 -0400
@@ -1381,6 +1381,115 @@
return ret;
}
+struct target_msqid_ds
+{
+ struct target_ipc_perm msg_perm;
+ target_ulong msg_stime;
+ target_ulong __unused1;
+ target_ulong msg_rtime;
+ target_ulong __unused2;
+ target_ulong msg_ctime;
+ target_ulong __unused3;
+ target_ulong __msg_cbytes;
+ target_ulong msg_qnum;
+ target_ulong msg_qbytes;
+ target_ulong msg_lspid;
+ target_ulong msg_lrpid;
+ target_ulong __unused4;
+ target_ulong __unused5;
+};
+
+static inline void target_to_host_msqid_ds(struct msqid_ds *host_md,
+ target_ulong target_addr)
+{
+struct target_msqid_ds *target_md;
+
+lock_user_struct(target_md, target_addr, 1);
+target_to_host_ipc_perm(&(host_md->msg_perm),target_addr);
+host_md->msg_stime = tswapl(target_md->msg_stime);
+host_md->msg_rtime = tswapl(target_md->msg_rtime);
+host_md->msg_ctime = tswapl(target_md->msg_ctime);
+host_md->__msg_cbytes = tswapl(target_md->__msg_cbytes);
+host_md->msg_qnum = tswapl(target_md->msg_qnum);
+host_md->msg_lspid = tswapl(target_md->msg_lspid);
+host_md->msg_lrpid = tswapl(target_md->msg_lrpid);
+unlock_user_struct(target_md, target_addr, 0);
+}
+
+static inline void host_to_target_msqid_ds(target_ulong target_addr,
+ struct msqid_ds *host_md)
+{
+struct target_msqid_ds *target_md;
+
+lock_user_struct(target_md, target_addr, 0);
+host_to_target_ipc_perm(target_addr,&(host_md->msg_perm));
+target_md->msg_stime = tswapl(host_md->msg_stime);
+target_md->msg_rtime = tswapl(host_md->msg_rtime);
+target_md->msg_ctime = tswapl(host_md->msg_ctime);
+target_md->__msg_cbytes = tswapl(host_md->__msg_cbytes);
+target_md->msg_qnum = tswapl(host_md->msg_qnum);
+target_md->msg_lspid = tswapl(host_md->msg_lspid);
+target_md->msg_lrpid = tswapl(host_md->msg_lrpid);
+unlock_user_struct(target_md, target_addr, 1);
+}
+
+static inline long do_msgctl(long first, long second, long ptr)
+{
+struct msqid_ds dsarg;
+int cmd = second&0xff;
+long ret = 0;
+switch( cmd ) {
+case IPC_STAT:
+case IPC_SET:
+target_to_host_msqid_ds(&dsarg,ptr);
+ret = get_errno(msgctl(first, cmd, &dsarg));
+host_to_target_msqid_ds(ptr,&dsarg);
+default:
+ret = get_errno(msgctl(first, cmd, &dsarg));
+}
+return ret;
+}
+
+struct target_msgbuf {
+ target_ulong mtype;
+ char mtext[1];
+};
+
+static inline long do_msgsnd(long msqid, long msgp, long msgsz, long msgflg)
+{
+struct target_msgbuf *target_mb;
+struct msgbuf *host_mb;
+long ret = 0;
+
+lock_user_struct(target_mb,msgp,0);
+host_mb = malloc(msgsz+sizeof(long));
+host_mb->mtype = tswapl(target_mb->mtype);
+memcpy(host_mb->mtext,target_mb->mtext,msgsz);
+ret = get_errno(msgsnd(msqid, host_mb, msgsz, msgflg));
+free(host_mb);
+unlock_user_struct(target_mb, msgp, 0);
+
+return ret;
+}
+
+static inline long do_msgrcv(long msqid, long msgp, long msgsz, long msgtype, long msgflg)
+{
+struct target_msgbuf *target_mb;
+struct msgbuf *host_mb;
+long ret = 0;
+
+lock_user_struct(target_mb,msgp,0);
+host_mb = malloc(msgsz+sizeof(long));
+ret = get_errno(msgrcv(msqid, host_mb, msgsz, 1, msgflg));
+if( ret > 0 )
+ memcpy(target_mb->mtext,host_mb->mtext,ret);
+target_mb->mtype = tswapl(host_mb->mtype);
+free(host_mb);
+unlock_user_struct(target_mb, msgp, 0);
+
+return ret;
+}
+
/* ??? This only works with linear mappings. */
static long do_ipc(long call, long first, long second, long third,
long ptr, long fifth)
@@ -1417,27 +1526,15 @@
break;
case IPCOP_msgsnd:
- ret = get_errno(msgsnd(first, (struct msgbuf *) ptr, second, third));
+ ret = do_msgsnd(first, ptr, second, third);
break;
case IPCOP_msgctl:
- ret = get_errno(msgctl(first, second, (struct msqid_ds *) ptr));
+ ret = do_msgctl(first, second, ptr);
break;
case IPCOP_msgrcv:
- {
- struct ipc
