qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [Qemu-devel] [PATCH] qemu-0.7.0 Solaris Host patch (Real)


From: Ben Taylor
Subject: Re: Re: [Qemu-devel] [PATCH] qemu-0.7.0 Solaris Host patch (Real)
Date: Fri, 6 May 2005 17:22:26 -0400

Juergen Keil <address@hidden> wrote:
> 
> 
> > I have retested on sparc (sol9), by adding some of the
> > defines in fenv.h for Solaris 10 to the gnu-c99-math.h 
> > file you created, and the patches you posted, and now 
> > I'm getting an error when I  compile that looks like this:
> > 
> > for d in i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu; do \
> > gmake -C $d all || exit 1 ; \
> >         done
> > gmake[1]: Entering directory 
> `/export/src/qemu-snapshot-2005-05-04_23-sol/i386-softmmu'
> > ../dyngen -c -o opc.h op.o
> > dyngen: ret; restore; not found at end of op_fstt_ST0_A0
> > gmake[1]: *** [opc.h] Error 1
> > gmake[1]: Leaving directory 
> `/export/src/qemu-snapshot-2005-05-04_23-sol/i386-softmmu'
> > gmake: *** [all] Error 1
> > 
> > Ideas?
> 
> 
> Which compiler was used?

blastwave's gcc-3.4.3

> 
> Disassemble the op_fstt_ST0_A0 function, using "dis -F op_fstt_ST0_A0 op.o".
> 
> My S10 sparc binary for op.o currently includes:
> 
> % dis -F op_fstt_ST0_A0 i386-softmmu/op.o
>                 ****   DISASSEMBLER  ****
> 
> 
> disassembly for i386-softmmu/op.o
> 
> section .text
> op_fstt_ST0_A0()
>     op_fstt_ST0_A0:         9d e3 bf 90  save         %sp, -0x70, %sp
>     op_fstt_ST0_A0+0x4:     40 00 00 00  call         op_fstt_ST0_A0+0x4
>     op_fstt_ST0_A0+0x8:     01 00 00 00  nop          
>     op_fstt_ST0_A0+0xc:     01 00 00 00  nop          
>     op_fstt_ST0_A0+0x10:    81 c7 e0 08  ret          
>     op_fstt_ST0_A0+0x14:    81 e8 00 00  restore      

dis -F op_fstt_ST0_A0 i386-softmmu/op.o
                ****   DISASSEMBLER  ****


disassembly for i386-softmmu/op.o

section .text
op_fstt_ST0_A0()
        cfe4:  9d e3 bf 90         save         %sp, -0x70, %sp
        cfe8:  40 00 00 00         call         0xcfe8
        cfec:  81 e8 00 00         restore      
        cff0:  01 00 00 00         nop      

interesting.    

> I've seen cases where gcc 3.4.x has compiled the op.o code templates into
> "leaf" functions, and these are incompatible with dyngen.  I think
> some extra gnu cc CFLAGS for op.c (-fno-omit-frame-pointer) fix this problem.

added those with no effect.  Do we need gas to do
this correctly? Blastwave's gcc uses sun's as and ld.

Ben






reply via email to

[Prev in Thread] Current Thread [Next in Thread]