From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LwoAV-00045a-Qt for qemu-devel@nongnu.org; Wed, 22 Apr 2009 21:56:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LwoAQ-00042S-4y for qemu-devel@nongnu.org; Wed, 22 Apr 2009 21:56:02 -0400 Received: from [199.232.76.173] (port=44239 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LwoAP-00042N-V4 for qemu-devel@nongnu.org; Wed, 22 Apr 2009 21:55:57 -0400 Received: from mx20.gnu.org ([199.232.41.8]:35187) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LwoAP-0007fE-Cx for qemu-devel@nongnu.org; Wed, 22 Apr 2009 21:55:57 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LwoAN-0004xH-Mh for qemu-devel@nongnu.org; Wed, 22 Apr 2009 21:55:56 -0400 Date: Wed, 22 Apr 2009 18:55:51 -0700 From: Nathan Froyd Subject: Re: [Qemu-devel] [PATCH 2/3] linux-user: ppc signal handling Message-ID: <20090423015551.GS22588@codesourcery.com> References: <1240367535-20081-1-git-send-email-froydnj@codesourcery.com> <1240367535-20081-3-git-send-email-froydnj@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org On Thu, Apr 23, 2009 at 05:22:55AM +0400, malc wrote: > On Tue, 21 Apr 2009, Nathan Froyd wrote: > > > Implement setup_{,rt_}frame and do_{,rt_}sigreturn for PPC 32-bit. Use > > the same TARGET_QEMU_ESIGRETURN hack as for MIPS to avoid clobbering > > register state on a sigreturn. > > With one modification i managed to make it compile and run on my system, > but: > > a) Why is it marked as second/third in the series (patch makred as > first has different subject and touches main ppc translation engine > and AFAICT doesn't have much to do with linux user bits)? The first patch moves the cpu capability flags to a place where save_user_regs and restore_user_regs can get at them. The main reason this is necessary is to choose between altivec and spe register save/restore, since the save area for those registers overlap. elfload.c in the third patch also uses the cpu capability flags. (I suppose if QEMU ever supports VSX, those flags will come in handy in the same place(s) as well. Maybe decimal float, too, since IIRC FPSCR is larger in DFP-supporting processors...) > > +/* Indices for target_mcontext.mc_gregs, below. > > + See arch/powerpc/include/asm/ptrace.h for details. */ > > +enum { > > + PT_R0 = 0, > > + PT_R1 = 1, > > + PT_R2 = 2, > > + PT_R3 = 3, > > + PT_R4 = 4, > > + PT_R5 = 5, > > + PT_R6 = 6, > > + PT_R7 = 7, > > + PT_R8 = 8, > > + PT_R9 = 9, > > + PT_R10 = 10, > > + PT_R11 = 11, > > + PT_R12 = 12, > > + PT_R13 = 13, > > + PT_R14 = 14, > > + PT_R15 = 15, > > + PT_R16 = 16, > > + PT_R17 = 17, > > + PT_R18 = 18, > > + PT_R19 = 19, > > + PT_R20 = 20, > > + PT_R21 = 21, > > + PT_R22 = 22, > > + PT_R23 = 23, > > + PT_R24 = 24, > > + PT_R25 = 25, > > + PT_R26 = 26, > > + PT_R27 = 27, > > + PT_R28 = 28, > > + PT_R29 = 29, > > + PT_R30 = 30, > > + PT_R31 = 31, > > + PT_NIP = 32, > > + PT_MSR = 33, > > + PT_ORIG_R3 = 34, > > + PT_CTR = 35, > > + PT_LNK = 36, > > + PT_XER = 37, > > + PT_CCR = 38, > > + /* Yes, there are two registers with #39. One is 64-bit only. */ > > + PT_MQ = 39, > > + PT_SOFTE = 39, > > + PT_TRAP = 40, > > + PT_DAR = 41, > > + PT_DSISR = 42, > > + PT_RESULT = 43, > > + PT_REGS_COUNT = 44 > > +}; > > b) This clashes with PT_ (save for PT_SOFTE) values that are "leaking" > through the headers that were previously included. To make it build > i replaced all instances of PT_ with QPT_ Is this because you're compiling on ppc? I'll update the patch to use TARGET_PT_*; I like the brevity of QPT_*, but TARGET_PT_* is more inline with linux-user conventions. > > + /* Set up the sigreturn trampoline: li r0,sigret; sc. */ > > + if (sigret) { > > + if (__put_user(0x38000000UL | sigret, &frame->tramp[0]) || > > + __put_user(0x44000002UL, &frame->tramp[1])) { > > c) For the reasons i can not really understand gcc-4.4.0 says: > > .../signal.c:3439: warning: large integer implicitly truncated to unsigned type > ^^^^ That's the 0x44000002UL line. I got this warning too and I'm really not sure how to make it go away. I've tried several things but none of them had any effect. -Nathan