qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Mac OS X issues


From: Joachim Henke
Subject: Re: [Qemu-devel] Mac OS X issues
Date: Sun, 11 Dec 2005 21:47:00 +0100

gcc4 and -fno-tree-ch did the trick for me, too.
-fno-tree-ch was mentioned earlyer on this list, to compile with gcc4 on OS X. But since gcc4 is still not in the default toolchain, I did not even try :(.

Seams that we have a problem with gcc3.3 and not gcc4 for once :)
The error behavement is similar on your machine. I also got bus error (Sometimes it did not reach the menu, too. I started to hit the 3 very early, so I could go right thru it... Early crashes always happened for me on MS-DOS 6.22 and DOS 7.

Tested it with DOS 6.22 and DOS 7 (win95). No Problems so far.

In the meanwhile I tracked down the whole thing a little bit. Debugging with GDB returns these messages when qemu (pure GCC3 build) crashes:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000034
0x000621e0 in tb_invalidate_phys_page_range (start=630485, end=630486, 
is_cpu_write_access=1) at /Volumes/Data/build/qemu/exec.c:491
491             tb2 = tb1->jmp_next[n1];

So one could assume that the problem is in exec.c - but some more compiling tests have shown, that GCC4 is required _only_ for cpu- exec.c. All other source files can be build with GCC3 and qemu will still run stable on Mac OS X (such a mixed build is probably faster than a pure GCC4 build). I feel indeed that the problem is somewhere in cpu-exec.c or one of its includes - maybe they init the data that exec.c crashes on. Hopefully I'm a bit luckier to find it tomorrow.

I hope Fabrice stumbles upon this.

Maybe we should make the Patch a little more selective with "ifeq ($ (CONFIG_DARWIN),yes)" and post it.
Don't know whether this affects other Platforms, too...

Yes, my patch was just a simple one for experimental purposes. It must not go into CVS since it breaks compilation with GCC3 or earlier. Despite the fact that GCC4 is required only for cpu-exec.c, I also think that building with GCC4 should be generally provided, since all emulated architectures compile cleanly with it (at least on Mac OS X).

Instead of requiring --disable-gcc-check, the configure script could write the option HAVE_GCC4=yes to config-host.mak, if it detects GCC4. The warning message could be kept. Makefile.target can then decide which CFLAGS should be used.

I could create such a patch if people agree.

Jo.




reply via email to

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