I made a simpler version of the Sparc64 patch which doesn't attempt to avoid
the stack use. All targets build on Sparc64 host. I copied the relevant
parts of the fixes to Sparc32 also.
The PPC patch is also updated, but I have no interest in maintaining this
patch in the future.
Requiring that ops don't use a stack frame doesn't seem like a realistic
constraint.
It can be done, see my latest patch. Of course there's no point doing it if
there is no real need.
> The remaining target specific problem with PPC FPU ops could be solved
by
> changing PPC to soft float. W
> I got the i386-user to build by moving the troublesome SSE ops to helper
> (only for Sparc32/64, no effect at least to x86 host). The emulator crashes
> when executing the first TB, code generation and register use could be
> suspected. The patch makes ops_sse.h more confusing to read. Any commen
I converted PPC to use soft float instead of native FPU. I don't have much
PPC software available, but at least some qemu-tests files work on an x86
host.
As I also fixed the bug with system emulators not passing final link (in
sparc64.ld), now all default user and softmmu targets can be built
I got the i386-user to build by moving the troublesome SSE ops to helper
(only for Sparc32/64, no effect at least to x86 host). The emulator crashes
when executing the first TB, code generation and register use could be
suspected. The patch makes ops_sse.h more confusing to read. Any comments?
The attached patch adds initial support to Sparc64 as host platform.
ARM, MIPS and Sparc32 user emulators compile, but at least the Sparc32
emulator segfaults when executing the first TB.
The final linking of the system emulators fail with a lot of the following
messages:
/usr/lib64/libc_nons