[Mono-list] Cannot run or build Mono on SPARC V8 / Solaris 9

Jonathan Zimmerman tyrius at verizon.net
Fri Jul 7 21:47:25 EDT 2006


After further investigation I was able to determine the cause of my 
problem.  According to the SPARC V8 manual any floating point operation 
that can result in a change of the floating point condition code (fcc 
portion, bits 10 and 11, of the float point state register) be following 
by a non-floating point operation before testing the fcc; failure to do 
so may result in undefined behavior.  The OP_FCOMPARE instruction emits 
an fcmpd.  If this is immediately followed by an OP_FBLT, OP_FBGT, 
OP_FBLT_UN, OP_FBGT_UN, or other similar IL instruction you will get 
assembly instructions that look similar to this:
fcmpd %f2, %f4
fbl,a 0xee864b2c
nop
fbun,a 0xee864b2c
nop

When stepping through the code using GDB I had a hard time getting the 
error to occur, however, when I added print and cont commands to a 
breakpoint I was able to clearly see the problem.  The solution is to 
add a sparc_nop(...) after the sparc_fcmpd(...) at line 3420 in 
mono/mini/mini-sparc.c.

I made this change last night; Mono has been building ever since (yes, 
it takes a LONG time on an old CPU).

Jonathan Zimmerman wrote:
> I have resolved the issue I previously identified: 
> mono/arch/sparc-codegen.h has a macro called sparc_flushw that uses a 
> SPARC V9 instruction that flushes all register windows.  The V8 
> instruction set includes an instruction with the same opcode, however as 
> the V8 instruction is a privileged instruction a SIGILL is raised when 
> attempting to use code that includes the sparc_flushw macor.
> As a convenience Solaris 9 provides a software trap that will accomplish 
> the same thing, so it is just a matter of using an #ifdef SPARCV9 in 
> sparc-codegen.h to use the hardware instruction if we're being build in 
> a V9 processor or the software trap if we're being build on a V8 (or V7) 
> processor.  After applying the provided patch I am able to get past the 
> SIGILL issue.
>
> However, when trying to compile anything via mcs.exe I get the following 
> error:
> Unhandled Exception: System.TypeInitializationException: An exception 
> was thrown by the type initializer for Mono.CSharp.Location ---> 
> System.ArgumentOutOfRangeException: load factor
> Parameter name: loadFactor
> in <0x002b8> System.Collections.Hashtable:.ctor (Int32 capacity, Single 
> loadFactor, IHashCodeProvider hcp, IComparer comparer)
> in <0x0002c> System.Collections.Hashtable:.ctor (Int32 capacity, Single 
> loadFactor)
> in <0x00024> System.Collections.Hashtable:.ctor ()
> in <0x00030> Mono.CSharp.Location:.cctor ()--- End of inner exception 
> stack trace ---
>
> in <0x00000> <unknown method>
> in <0x0000c> Mono.CSharp.Driver:Main (System.String[] args)
> This error happens on both mono 1.1.9 and mono 1.1.13.8; I have not been 
> able to get past it.
>
> I disassembled the basic mscorlib.dll and saw that the default 
> loadFactor value is 1f.  How is it possible that in the Hashtable 
> constructor(Int32, Single, IHashCodeProvider , IComparer) the loadFactor 
> value is being seen as not 1.0?
>
> Thanks!
>
> tyrius at verizon.net wrote:
>   
>> When I try to use the prepared Mono 1.1.13.8 package on a SPARCStation 5/170 running Solaris 9 I get this error:
>>   cannot execute binary file.
>>
>> file `which mono` produces this output:
>>   ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped
>>
>> I believe the problem here is that the mono executable was compiled on a SPARC V8+, but the cpu on my machine is a V8.
>>
>> I have attempted to rebuild Mono on my own (a very slow process on this machine), but that fails with a different problem.  During the build process I get the following (note the Illegal Instruction - core dumped):
>> gmake[6]: Entering directory `/home/tyrius/src/mono-1.1.13.8/mcs'
>> *** The compiler 'mcs' doesn't appear to be usable.
>> *** Trying the 'monolite' directory.
>> gmake[7]: Entering directory `/home/tyrius/src/mono-1.1.13.8/mcs'
>> Illegal Instruction - core dumped
>> gmake[8]: *** [build/deps/basic-profile-check.exe] Error 132
>> gmake[8]: Entering directory `/home/tyrius/src/mono-1.1.13.8/mcs'
>> *** The contents of your 'monolite' directory may be out-of-date
>> *** You may want to try 'make get-monolite-latest'
>> gmake[8]: *** [do-profile-check-monolite] Error 1
>> gmake[8]: Leaving directory `/home/tyrius/src/mono-1.1.13.8/mcs'
>> gmake[7]: *** [do-profile-check] Error 2
>> gmake[7]: Leaving directory `/home/tyrius/src/mono-1.1.13.8/mcs'
>> gmake[6]: *** [do-profile-check-monolite] Error 2
>> gmake[6]: Leaving directory `/home/tyrius/src/mono-1.1.13.8/mcs'
>> gmake[5]: *** [do-profile-check] Error 2
>> gmake[5]: Leaving directory `/home/tyrius/src/mono-1.1.13.8/mcs'
>> gmake[4]: *** [profile-do--basic--all] Error 2
>> gmake[4]: Leaving directory `/home/tyrius/src/mono-1.1.13.8/mcs'
>> gmake[3]: *** [profiles-do--all] Error 2
>> gmake[3]: Leaving directory `/home/tyrius/src/mono-1.1.13.8/mcs'
>> gmake[2]: *** [all-local] Error 2
>> gmake[2]: Leaving directory `/home/tyrius/src/mono-1.1.13.8/runtime'
>> gmake[1]: *** [all-recursive] Error 1
>> gmake[1]: Leaving directory `/home/tyrius/src/mono-1.1.13.8'
>> gmake: *** [all] Error 2
>>
>> I find it a little puzzling: I've tried to use GDB to see where the illegal instruction is coming from, but in sigill_signal_handler info->si_code == 0.
>>
>> Here is the backtrace from GDB:
>> #0  sigill_signal_handler (_dummy=4, info=0xefffebd0, context=0xefffea10) at mini.c:9924
>> #1  0xef2c5b14 in __sighndlr () from /usr/lib/libthread.so.1
>> #2  0xef2bf80c in call_user_handler () from /usr/lib/libthread.so.1
>> #3  <signal handler called>
>> #4  0xef1f0010 in ?? ()
>> #5  0xee8628b4 in ?? ()
>> #6  0xee8627e8 in ?? ()
>> #7  0x0016e544 in mono_jit_runtime_invoke (method=0x308910, obj=0x271f90, params=0xeffff4e8, exc=<incomplete type>) at mini.c:9869
>> #8  0x000a3800 in mono_runtime_invoke (method=0x308910, obj=0x271f90, params=0xeffff4e8, exc=<incomplete type>) at object.c:1352
>> #9  0x000d3f1c in mono_exception_from_name_two_strings (image=0x271f90, name_space=0x0, name=0x31b360 "", a1=0x30bfc8, a2=0x0) at exception.c:142
>> #10 0x000d4894 in mono_runtime_init (domain=<incomplete type>, start_cb=0x166e48 <mono_thread_start_cb>, attach_cb=0x166ef4 <mono_thread_attach_cb>) at appdomain.c:123
>> #11 0x0016f8bc in mini_init (filename=0xeffff975 "/home/tyrius/src/mono-1.1.13.8/mcs/class/lib/monolite/mcs.exe") at mini.c:10492
>> #12 0x000263e8 in mono_main (argc=6, argv=0xeffff7cc) at driver.c:867
>> #13 0x00023ba0 in main (argc=6, argv=0xeffff7cc) at main.c:6
>>
>> the box I'm doing this on is a hobbyist box and I don't have the luxury of replacing it with something that has a SPARC V9 cpu, so I'd really like to get this working on a SPARC V8.
>>
>> Thank you,
>>
>> Jonathan Zimmerman
>>     


More information about the Mono-list mailing list