[Mono-dev] Interpreter?

Andreas Färber andreas.faerber at web.de
Tue Jul 3 08:31:08 EDT 2007

Hi Paolo,

>> I am stuck with my ppc64 port of the JIT so I was hoping to test the
>> interpreter to see if that works.
> Event if the interpreter compiled, it wouldn't work on ppc64.
> It would be better if you detailed the issues you have with the ppc64
> port instead because we could help you with that.
> Thanks!

Due to its size I uploaded my unfinished patch to Bugzilla:


First, it includes changes to eglib/configure.in to make it compile  
on OS X and adds VPATH support to facilitate compiling for ppc and  
configure.in is patched to define POWERPC or POWERPC64 depending on  
the pointer size (and a workaround fixes building monoburg w/eglib on  
OS X for now).
Next, it reorganizes the ppc-codegen.h (header still needs some  
changes Miguel requested) - instructions are now listed  
alphabetically separated from the mnemonics with additions and  
updates for the 64-bit and 32-bit-only instructions.
Then, the mini and arch ppc files were updated with #ifdefs for ppc64  
doing all kinds of necessary changes. I have some FIXMEs/CHECKMEs in  
there, especially some numeric offsets and alignments are unclear to  
me. This is where I suspect the most issues.
Finally, all occurrences of ppc in the sources were checked and adapted.


I configure Mono --with-gc=none --with-glib=embedded --with-ikvm- 
native=no while exporting CC="gcc -arch ppc64" (as well as setting  
appropriately), using a ppc Mono installation of the same revision  
for bootstrapping. (configuring without GC first to rule that out as  
a source of errors)


Test system was a PowerMac G5 dual-core with OS X v10.4.8/9/10.

The ppc Mono is symlinked from /Library/Mono.framework and used "for  
production" - it works fine with this patch applied as far as I can  
tell. There are no other potentially conflicting Mono installations.

The ppc64 Mono runtime compiles fine. Fixing some earlier bugs it now  
runs like a normal app so I can kill it using Ctrl+C. However, on  
compilation of System.dll using the new mono (or on execution of a  
hello world assembly) it aborts with empty stacktrace:

MONO_PATH="../../class/lib/basic:$MONO_PATH" /Users/andreas/Mono/mono- 
ppc64/mono/runtime/mono-wrapper  ../../class/lib/basic/mcs.exe / 
codepage:65001   -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB - 
debug /noconfig -define:XML_DEP -r:System.Xml.dll -target:library - 
out:System.dll  @System.dll.sources

make[8]: *** [../../class/lib/basic/System.dll] Abort trap

$ mono/mini/mono ../../../testassembly.exe

Abort trap

According to gdb and some printfs it appeared to enter an infinite  
loop on exception handling during JIT initialization leading to, I  
assume, stack overflow:

$ gdb mono/mini/mono
GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:54:33  
GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
This GDB was configured as "powerpc-apple-darwin"...Reading symbols  
for shared libraries ... done

(gdb) run ../../../testassembly.exe
Starting program: /Users/andreas/Mono/mono-ppc64/mono/mono/mini/ 
mono ../../../testassembly.exe
Reading symbols for shared libraries .++ done

Program received signal SIGBUS, Bus error.
0x0000000000000000 in ?? ()

I haven't been able to locate the error(s) for several months now and  
would appreciate any hints that could lead to some more progress.



More information about the Mono-devel-list mailing list