Re: [Gcc4cli-devel] Running CLI code on Linux/SPARC64

[Erven R. <erv...@in...>]

Hello everybody,

I understand that we assume 32-bit pointers.
But about endianness: I remember that we generate initializers for both, and a 
small run-time check to pick the right one. What are the cases where we have 
problems?

--
Erven.


Andrea Carlo Ornstein a écrit :
> Hi,
> 
> the libraries are in pure CLI and are portable in compatible machine
> families (same pointer size, same endianness).
> by default we compile little endian, 32bit pointer size
> the 64bit pointer size was in the plans but we never got the time to
> actually do it.
> 
> Now, looking at the errors you report.
> The first one, I guess was already reported from Erven and it's
> probably an error in Mono
> if I recall it correctly it mishandled a CLI copy object instruction
> when passed an unmanaged pointer (it happens in initialization of
> global variables)
> 
> The second problem you have is in the assembler.
> you can compile with -S and see how the assembly file looks like, it
> should be the same on x86 and on sparc.
> If so the error is in the as tool you are using that is ilasm (from Mono again).
> 
> Andrea
> 
> 
> On Wed, Mar 3, 2010 at 11:29 AM, Thierry Lafage <thi...@in...> wrote:
>> Hi all,
>>
>> I'm currently in trouble to run a gcc4cli compiled CLI code (compiled on
>> Linux/x86 machine) on a Linux/SPARC64 box with Mono (hello.exe simply printf
>> "Hello World"):
>>
>> $ ls
>> gcc4net.dll  hello.exe  libstd.dll  MSCorelibWrapper.dll
>> $ mono hello.exe
>>
>> Unhandled Exception: System.NullReferenceException: Object reference not set
>> to an instance of an object
>>   at libstd.Obj?10?COBJ?init () [0x00000] in <filename unknown>:0
>>   at libstd..init () [0x00000] in <filename unknown>:0
>>   at hello..init () [0x00000] in <filename unknown>:0
>>   at hello..start (System.String[] args) [0x00000] in <filename unknown>:0
>>
>> All the DLLs come from gcc4cli compiled on the x86 box. I thought these DLLs
>> would work fine but this is not the case.
>> So I tried to compile gcc4cli on the SPARC64 box in order to get these DLLs
>> fine. But the build failed:
>>
>> $ ../../gcc-src/gcc/configure --target=cil32 --enable-languages=c
>> --disable-bootstrap --prefix=/local/lafage/gcc/image
>> --with-local-prefix=/local/lafage/gcc/image/cil32
>> --with-mpfr=/local/lafage/misc --with-gmp=/local/lafage/misc
>> [...]
>> $ make
>> [...]
>> if /udd/lafage/local/gcc/gcc-build/gcc/./gcc/xgcc
>> -B/udd/lafage/local/gcc/gcc-build/gcc/./gcc/
>> -B/local/lafage/gcc/image/cil32/bin/ -B/local/lafage/gcc/image/cil32/lib/
>> -isystem /local/lafage/gcc/image/cil32/include -isystem
>> /local/lafage/gcc/image/cil32/sys-include -DHAVE_CONFIG_H -I.
>> -I../../../../../gcc-src/gcc/libstd/src -I..    -nostdinc -iwithprefix
>> include -I../../../../../gcc-src/gcc/libstd/include -g -O2   -MT
>> libstd_dll-__io_fout.o -MD -MP -MF ".deps/libstd_dll-__io_fout.Tpo" -c -o
>> libstd_dll-__io_fout.o `test -f '__io_fout.c' || echo
>> '../../../../../gcc-src/gcc/libstd/src/'`__io_fout.c; \
>>         then mv -f ".deps/libstd_dll-__io_fout.Tpo"
>> ".deps/libstd_dll-__io_fout.Po"; else rm -f
>> ".deps/libstd_dll-__io_fout.Tpo"; exit 1; fi
>> /tmp/ccKF1tBh.s (2014, 36):
>> Unhandled Exception: System.ArgumentException: Destination array is not long
>> enough to copy all the items in the collection. Check array index and
>> length.
>>   at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src,
>> Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0
>>   at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex)
>> [0x00000] in <filename unknown>:0
>>   at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename
>> unknown>:0
>>   at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd)
>> [0x00000] in <filename unknown>:0
>>   at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path)
>> [0x00000] in <filename unknown>:0
>> make[4]: *** [libstd_dll-__io_fout.o] Error 1
>>
>> Note that I recompiled mpfr and gmp in 32-bit mode.
>>
>> So I have 2 questions:
>>
>> Is it normal that gcc4li DLLs are not portable since they are .NET
>> assemblies?
>> Are there special configuration options to compile gcc4cli on SPARC64?
>>
>> Thanks for any help,
>>
>> Thierry Lafage.
>>