Re: [Qemu-devel] SUNWqemu-0.8.2,REV=2006.10.14-sol8-sparc-opt.pkg released

[Martin Bochnig <mb1x@gmx.com>]

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)?