Re: [Qemu-devel] [PATCH 2/3] linux-user: ppc signal handling

[Nathan Froyd <froydnj@codesourcery.com>]

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