> Thanks for your feedback. I've added additional check to dyngen.c, which
> checks that function has either save; in the beginning and ret; restore;
> in the end, or ends in retl; nop;. That allowed me to get past the arm
> target build failure. Now it fails (during dyngen check) on ppc target,
> the culprit is the following function:
>
> 000033d8 <op_stfs_raw>:
> 33d8: 9c 03 bf 90 add %sp, -112, %sp
> 33dc: d1 19 a0 f8 ldd [ %g6 + 0xf8 ], %f8
> 33e0: 91 a0 18 c8 fdtos %f8, %f8
> 33e4: d1 23 a0 64 st %f8, [ %sp + 0x64 ]
> 33e8: c8 03 a0 64 ld [ %sp + 0x64 ], %g4
> 33ec: 99 39 20 18 sra %g4, 0x18, %o4
> 33f0: 97 39 20 10 sra %g4, 0x10, %o3
> 33f4: 95 39 20 08 sra %g4, 8, %o2
> 33f8: c8 28 60 03 stb %g4, [ %g1 + 3 ]
> 33fc: d8 28 40 00 stb %o4, [ %g1 ]
> 3400: d6 28 60 01 stb %o3, [ %g1 + 1 ]
> 3404: d4 28 60 02 stb %o2, [ %g1 + 2 ]
> 3408: 81 c3 e0 08 retl
> 340c: 9c 23 bf 90 sub %sp, -112, %sp
>
> What should dyngen do about a function like that?
Maybe a better strategy is to force generation of a register window save with
the FORCE_RET macro.
#define FORCE_RET() asm volatile("":::"o0");
Seems to do the trick.
Paul
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
