Blue Swirl wrote: > Is there some problem that can't be fixed with the sparc64.ld instead > of disabling it for Solaris?
Yes and no. The problem is gnu-ld vs. sun-ld, rather than Linux vs. Solaris. I cannot find an equivalent option for sun-ld. 32bit sparc.ld is also disabled under Solaris for that reason, and has always been. OpenSolaris is still based on its own SUNW-toolchain, not on binutils. (though I'm not sure about Nextenda/GNU-Solaris) Even though OpenSolaris can optionally be compiled with SUNW's gcc 3.4.x now (/usr/sfw/bin/gcc), it still uses its own /usr/ccs/bin/as and ld. All gcc-packages offered on Solaris freeware sites are also built not to use gas or gnu-ld. If you simply make a dirty symlink to /usr/ccs/bin/[as|ld] small things may build and link just good enough. But qemu doesn't, because certain dependencies (like -lm) are skipped / not considered valid, for some reason. It all _might_ potentially work when one would build a complete toolchain only for the purpose of getting qemu built with sparc32: LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc.ld and sparc64: LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc64.ld But the resulting performance benefit may be zero, if not negative: SUNW's assembler and linker are not bad, especially on sparc. > > The ARM/MIPS bits could be rewritten more generally with #ifdef AREG0 > instead of _sparc_. Maybe these would be better handled once in > dyngen-exec.h so that that the targets don't assume they get any asm > registers. Yes, of course. But I plan to use a faster method and to actually use as much as possible physical host registers (see sparc-target directly below). > Why do you reorder the registers in Sparc? Dumb trying-out is sometimes the only wayout: I *tried* all possible combinations of registers in a systematic testing-approach (I only did this on the sparc-target so far, need to do the same for mips and arm). The assignments in the patch are the best I could get (as many as possible fast host registers, rather than slow main memory locations). Any other order of assignments resulted in segfaults. That's why everything appears to be out of order in target-sparc/exec.h. And if I would bring target-sparc/exec.h in order again, by changing the AREG assignments in dyngen-exec.h, I would mess up all the other targets like i386-softmmu and x86_64-softmmu. One odd observation: If I try to make use of AREG1 in target-sparc/exec.h, it would _always_ result in a segfault in gen_code_buffer(), no matter at all, which physical sparc host-register I would have assigned to AREG1 in dyngen-exec.h. There is something that makes AREG1 itself unusable on sparc hosts for all other emulation targets, except i386-softmmu, x86_64-softmmu (and maybe ppc-softmmu). > > The int64_t issue could be checked with configure, resulting in > HAS_INT64 #defined as needed. Yep. Thanks for your feedback. And for your good work on the sparc target(s). The Solaris_sparc guest 32bit kernel still died a month ago, did you make progress? Are there ways to lern from the now open source sun4v's OBP to see, what SUNW's proprietary OBP handles differently, when compared to the public ieee1275-1994 standard or other implementations like SmartFirmware? (wasn't there a "SUNW-compatibility" #ifdef in SmartFirmware [I don't have that code] ? ) May it be possible, to employ SUNW's sun4v OBP in a potential future sun4v emulation target (i.e. as -M option of sparc64-softmmu)? _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
