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

[malc]

On Wed, 22 Apr 2009, Nathan Froyd wrote:

> 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...)

Thing is i applied patches 2 and 3 and things just worked thus questioned
the utility of patch 1.

[..snip..]
 
> > 
> > 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.

I'm compiling on a ppc yes, as for TARGET_PT_, sure, will do just as fine.
 
> > > +    /* 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.

Puzzling that..

-- 
mailto:address@hidden