[Top][All Lists]

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

[Qemu-devel] Re: Some patches for qemu on sparc

From: Jurij Smakov
Subject: [Qemu-devel] Re: Some patches for qemu on sparc
Date: Sun, 12 Feb 2006 21:20:25 -0800 (PST)

On Sun, 12 Feb 2006, Blue Swirl wrote:

Sorry, I am not familiar with qemu internals enough to understand that. It currently fails the build in the sanity check implemented in dyngen.c. We figured out so far that there might be two valid cases: save;...ret;restore; and ....;retl;nop;. Are you saying that the function ending in retl;some_insn; is valid as well and the check has to be modified yet again to accomodate this (third) case?

Yes, though the second case can be seen a special case of the third.

Right. I've modified the check and now it goes further in the build. The next failure I'm hitting is:

make[2]: Entering directory `/home/jurij/qemu/qemu-0.8.0/i386-softmmu'
gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 -I. -I/home/jurij/qemu/qemu-0.8.0/./target-i386 -I/home/jurij/qemu/qemu-0.8.0/. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/jurij/qemu/qemu-0.8.0/./fpu -DHAS_AUDIO -I/home/jurij/qemu/qemu-0.8.0/./slirp -c -o vl.o /home/jurij/qemu/qemu-0.8.0/./vl.c
/home/jurij/qemu/qemu-0.8.0/./vl.c:552:2: #error unsupported CPU
/home/jurij/qemu/qemu-0.8.0/./vl.c: In function `cpu_get_ticks':
/home/jurij/qemu/qemu-0.8.0/./vl.c:563: warning: implicit declaration of function `cpu_get_real_ticks'
make[2]: *** [vl.o] Error 1
make[2]: Leaving directory `/home/jurij/qemu/qemu-0.8.0/i386-softmmu'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/jurij/qemu/qemu-0.8.0'
make: *** [debian/stamp-makefile-build] Error 2

Looks like there is no cpu_get_real_ticks() function implementation for sparc. There is an old message on qemu-devel discussing this issue [0].
It looks like this function is fairly easy to implement by reading the
%tick register in machines compliant with SPARC v9 architecture (Ultra1
or better), however the implementation for v8 architecture (and we are building binaries for v8 in Debian) does not look so simple. I'd appreciate any opinions or hints on this matter.

Best regards,

Jurij Smakov                                        address@hidden
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

reply via email to

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