[Mono-list] Adding Solaris/amd64 support

Paolo Molaro lupus at ximian.com
Wed Mar 7 11:59:13 EST 2007


On 03/05/07 Andreas Färber wrote:
> With or without this patch, compiled 32-bit or 64-bit, on the amd64  
> system I get the following warning in mono at runtime:
> 
> GC Warning: Large stack limit(10485760): only scanning 8 MB

This should likely be investigated, since I don't think we use stacks of
that size anywhere.

> During compilation for amd64, mono (r73669, with and without GC) then  
> outputs the following:
> 
> 
> TYPE: 1
> 
> ** ERROR **: file mini-amd64.c: line 180 (amd64_patch): assertion  
> failed: (amd64_is_imm32 (disp))
[...]
> According to bug #79271 the above assertion failure was supposed to  
> be fixed:
> http://bugzilla.ximian.com/show_bug.cgi?id=79271
> 
> Might I need to patch anything else for Solaris/amd64? Or should I  
> reopen that bug?

The amd64 code assumes in many places that executable code is reachable
within +/- 2 GB, because that allows using a faster code sequence.
On Linux the code we produce is stored in pages allocated with the
MAP_32BIT mmap option and this usually makes the above assumption be
true (there are still issues possible even with this option).
So as a first thing, you should check if solaris/amd64 has a similar
mmap() option: you should reserve the memory from the lower 32 bit
virtual memory space. The code is in utils/mono-mmap.c and
mono-codeman.c (grep for 32BIT).

If this solution is not available or it is not working, the real fix
will need to be implemented in utils/mono-codeman.c: at startup a large
chunk of virtual memory needs to be reserved and instead of using
mono_valloc directly, chunks from this memory area are taken. This
ensures all the generated code is within the memory bounds reachable
from the call instruction. Additionally the memory would need to be
reserved close to the address space where the program and shared
libraries are loaded (or the jit code must be changed to always call
native code with an indirect instruction).

This last solution is what I have in my todo list as a way to speedup
the generated code for architectures where a call instruction can't
reach all the address space (basically anything but x86). I have no idea
when I'll actually get to that todo item...

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better


More information about the Mono-list mailing list