[Qemu-devel] port to netbsd (was: FreeBSD != *BSD)

[Qemu-devel] port to netbsd (was: FreeBSD != *BSD)

[David Howland]

the problem seems to be that bswap.h tries to define functions named 
bswap16 and bswap32, when NetBSD already uses these names.  They 
conflict with stuff in sys/byte_swap.h that comes from when dyngen.c 
includes fcntl.h.  At this point, I dunno what to do.
suggestions?

-d

[Qemu-devel] Re: port to netbsd

[Ben Pfaff]

David Howland <dhowland@ecs.umass.edu> writes:

> the problem seems to be that bswap.h tries to define functions named
> bswap16 and bswap32, when NetBSD already uses these names.  They
> conflict with stuff in sys/byte_swap.h that comes from when dyngen.c
> includes fcntl.h.  At this point, I dunno what to do.

Rename one set of functions or the other.  It's probably easier
to rename qemu's set.
-- 
"Premature optimization is the root of all evil."
--D. E. Knuth, "Structured Programming with go to Statements"

Re: [Qemu-devel] Re: port to netbsd

[Paul Brook]

On Wednesday 01 September 2004 03:38, David Howland wrote:
> Ben Pfaff wrote:
>  > Rename one set of functions or the other.  It's probably easier
>  > to rename qemu's set.
>
> ya, I did that.  Just took the hacksaw to it.  I similarly hacked up a
> few other places.  I guess I'll just hack it until it compiles, then
> I'll worry about making it clean.  Anyway, it gets somewhat further now,
> but stops at the following...
>
> ---------------------------------------------------------------
> /usr/pkg/gcc3/bin/gcc -Wall -O2 -g -fno-strict-aliasing
> -fomit-frame-pointe     referred-stack-boundary=2 -malign-functions=0
> -I. -I/home/dave/build/qemu-0     target-i386
> -I/home/dave/build/qemu-0.6.0 -D_GNU_SOURCE -I/home/dave/build/
> 0.6.0/slirp -c -o op.o /home/dave/build/qemu-0.6.0/target-i386/op.c
> cc1: warning: -malign-functions is obsolete, use -falign-functions
> ../dyngen -o op.h op.o
> dyngen: ret or jmp expected at the end of op_divb_AL_T0
> gmake[1]: *** [op.h] Error 1
> gmake[1]: Leaving directory `/home/dave/build/qemu-0.6.0/i386-softmmu'
> ---------------------------------------------------------------
>
> This one actually does have me stumped.  I don't really see how this is
> a NetBSD issue.  So...any hints?

Sorry if you've already mentioned this, but what gcc version are you using?

There are known problems with some versions of gcc (3.4.x at least). Other 
versions need specific flags, eg. -fno-reorder-blocks.

Basically dyngen expects each function to end in a single "ret" instruction. 
Some gcc versions break this assumption.

Paul

Re: [Qemu-devel] Re: port to netbsd

[Bochnig, Martin]

I get exactly the same errors when trying to compile for SPARC64 (both 
Linux and Solaris10).
Giving up.

For SPARC32 it helped to use gcc 2.95 or 2.96 instead of gcc3.1/2/3x
Curiously enough gcc3.4.1 didn't show this error.
Install gcc2.9x into a separate location and try again.
While you will get many more warnings and errors, it may help to fix 
that damn (hopeless) './dyngen -o op.h op.o' bugs.



David Howland wrote:
> Ben Pfaff wrote:
Anyway, it gets somewhat further now,
> but stops at the following...
> 
> ---------------------------------------------------------------
> /usr/pkg/gcc3/bin/gcc -Wall -O2 -g -fno-strict-aliasing 
> -fomit-frame-pointe     referred-stack-boundary=2 -malign-functions=0 
> -I. -I/home/dave/build/qemu-0     target-i386 
> -I/home/dave/build/qemu-0.6.0 -D_GNU_SOURCE -I/home/dave/build/ 
> 0.6.0/slirp -c -o op.o /home/dave/build/qemu-0.6.0/target-i386/op.c
> cc1: warning: -malign-functions is obsolete, use -falign-functions
> ../dyngen -o op.h op.o
> dyngen: ret or jmp expected at the end of op_divb_AL_T0
> gmake[1]: *** [op.h] Error 1
> gmake[1]: Leaving directory `/home/dave/build/qemu-0.6.0/i386-softmmu'
> ---------------------------------------------------------------
> 
> This one actually does have me stumped.  I don't really see how this is 
> a NetBSD issue.  So...any hints?
> thnx,

Re: [Qemu-devel] Re: port to netbsd

[Bochnig, Martin]

Do you have at least binutils 2.13?

Re: [Qemu-devel] Re: port to netbsd

[David Howland]

Ben Pfaff wrote:
 > Rename one set of functions or the other.  It's probably easier
 > to rename qemu's set.

ya, I did that.  Just took the hacksaw to it.  I similarly hacked up a 
few other places.  I guess I'll just hack it until it compiles, then 
I'll worry about making it clean.  Anyway, it gets somewhat further now, 
but stops at the following...

---------------------------------------------------------------
/usr/pkg/gcc3/bin/gcc -Wall -O2 -g -fno-strict-aliasing 
-fomit-frame-pointe     referred-stack-boundary=2 -malign-functions=0 
-I. -I/home/dave/build/qemu-0     target-i386 
-I/home/dave/build/qemu-0.6.0 -D_GNU_SOURCE -I/home/dave/build/ 
0.6.0/slirp -c -o op.o /home/dave/build/qemu-0.6.0/target-i386/op.c
cc1: warning: -malign-functions is obsolete, use -falign-functions
../dyngen -o op.h op.o
dyngen: ret or jmp expected at the end of op_divb_AL_T0
gmake[1]: *** [op.h] Error 1
gmake[1]: Leaving directory `/home/dave/build/qemu-0.6.0/i386-softmmu'
---------------------------------------------------------------

This one actually does have me stumped.  I don't really see how this is 
a NetBSD issue.  So...any hints?
thnx,
d

Re: [Qemu-devel] port to netbsd

[Bochnig, Martin]

David Howland wrote:
> Well, I managed to get it to compile on NetBSD.  I had to use gcc 2.95 
> to do it, because of the dyngen errors.
> 
> So, NetBSD can run Linux binaries, and at first, I was trying to run the 
> 0.6.0 binaries from the frontpage. 

Congrats!

I don't run *BSD (I downloaded FreeBSD but it didn't install on my AMD32 
PC due to IDE controller probing hangs).

BTW: I started with running the prebuilt QEMU 0.6.0 Linux_i386 binary on 
my Solaris10_x86 host too.
I used the user space Linux_x86<<--->>Solaris_x86 ELF system call 
translator 'lxrun0.9.5' for that purpose.
It has no support for LKM (loadable kernel modules) nor does it support 
too kernel specific system calls.
LXrun runs most linux binaries - but unfortunately neither wine nor 
VMware or old Plex86.
*But it does run QEMU - thanx to Fabrice's brilliant design.*

Luckily did I get QEMU 0.6.0 compiled for Solaris10_x86 (with the help 
of Eric's patch - slightly upgraded and applied by hand [version mismatch]).

Yes - either supply the diffs or offer your source tree including the 
built files as package.
I assume the NetBSD would be very happy about that.

'/usr/local/bin/qemu' runs perfectly, stable and as fast as under Fedora 
core 2.
The other targets (qemu-fast, qemu-ppc and so on) did compile even under 
Solaris10_x86. But they crash with a segfault when run.
Slirp didn't compile and needed to be disabled.



--
	Martin

Re: [Qemu-devel] Re: port to netbsd

[David Howland]

Paul Brook wrote:
> Sorry if you've already mentioned this, but what gcc version are you using?

I'm using gcc 3.3 with binutils 2.15

Re: [Qemu-devel] Re: port to netbsd

[David Howland]

Bochnig, Martin wrote:

> I get exactly the same errors when trying to compile for SPARC64 (both 
> Linux and Solaris10).
> Giving up.

Looks like I'm going to aswell.

> 
> For SPARC32 it helped to use gcc 2.95 or 2.96 instead of gcc3.1/2/3x
> Curiously enough gcc3.4.1 didn't show this error.
> Install gcc2.9x into a separate location and try again.
> While you will get many more warnings and errors, it may help to fix 
> that damn (hopeless) './dyngen -o op.h op.o' bugs.
> 

Sounds like a stretch...
Maybe I should wait until qemu matures a little more before I play the 
porting game.  Is this dyngen something that can be upgraded/replaced?
-d

Re: [Qemu-devel] port to netbsd

[David Howland]

Well, I managed to get it to compile on NetBSD.  I had to use gcc 2.95 
to do it, because of the dyngen errors.

So, NetBSD can run Linux binaries, and at first, I was trying to run the 
0.6.0 binaries from the frontpage.  The emulator was incredibly slow.  I 
tried putting Windows 98 in as a guest OS and basically it took hours to 
boot up.  I figure the linux emulation was causing problems so I went 
about compiling it.  Well, I just got it to work, and tried it again...

Still slow.  Incredibly slow.  There is something very wrong here.  I 
startup qemu, it begins to boot, and I watch top to see whats eating my 
processor.  It turns out my system is almost completely idle.  qemu is 
technically going, as the screen does change sometimes, but its mostly 
just sitting there.  From what I know of Windows98, i think it is 
testing the memory during this period of bootup.  Does that sound like 
something that would cause this inactivity?

Suddenly, processor utilization shoots up.  The guest OS is responsive 
again.  Still not very fast, but that could just be my 5 year-old 500MHz 
machine.

Anyway, its compiling on NetBSD 1.6.2, should I submit a diff?

-d

Re: [Qemu-devel] Re: port to netbsd

[Bochnig, Martin]

David Howland wrote:
> Is this dyngen something that can be upgraded/replaced?
Of course, you already have the sources.
look into your QEMU src root.
Start with reading the technical qemu docs at bellard.org .

Martin

Re: [Qemu-devel] Re: port to netbsd

[David Howland]

If only I could....
I basically suck at programming.  I can get by for what I need to do, 
but as far as coding something like that, I'm out of my league.

Bochnig, Martin wrote:
> Of course, you already have the sources.
> look into your QEMU src root.
> Start with reading the technical qemu docs at bellard.org .

Re: [Qemu-devel] Re: port to netbsd

[Richard Zidlicky]

On Tue, Aug 31, 2004 at 08:34:59PM -0700, David Howland wrote:
> Bochnig, Martin wrote:
> 
> >I get exactly the same errors when trying to compile for SPARC64 (both 
> >Linux and Solaris10).
> >Giving up.
> 
> Looks like I'm going to aswell.
> 
> >
> >For SPARC32 it helped to use gcc 2.95 or 2.96 instead of gcc3.1/2/3x
> >Curiously enough gcc3.4.1 didn't show this error.
> >Install gcc2.9x into a separate location and try again.
> >While you will get many more warnings and errors, it may help to fix 
> >that damn (hopeless) './dyngen -o op.h op.o' bugs.
> >
> 
> Sounds like a stretch...
> Maybe I should wait until qemu matures a little more before I play the 
> porting game.  Is this dyngen something that can be upgraded/replaced?

no, just make sure you don't compile op.o with fomit-frame-pointer

Richard