[Mono-list] Tried building mono-0.11 on StrongARM

Paolo Molaro lupus@ximian.com
Mon, 29 Apr 2002 18:25:03 +0200


On 04/26/02 Jeff Steele wrote:
> 	I'm really excited about mono so I tried something a litle
> goofy : I built it on a Strongarm platform.  I *know* this isn't the
> highest priority right now, but just for kicks, here's what I did :
> 
> ./configure :
> I added "armv4l" as a target
> 
>          arm-*-linux-* | armv4l-*-linux-*) TARGET=ARM; arch_target=arm; ACCESS_UNALIGNED="no";;
>                        ^^^^^^^^^^^^^^^^^^
> ./arch/arm/tramp.c :  
> I removed mono_string_new_wrapper(), since it is defined elsewhere,
> and I was getting conflicts

I committed to cvs a fix for these two issues.

> ./io-layer/atomic.c :
> I removed the spinlocks.  This is a hack : pthreads doesn't have the
> spinlock calls on ARM, multi-cpus not supported. Should the atomic 
> routines be coded in assembly ?  Does it matter ?

I filed bug#24002 for this one.

> After these hacks, I did configure, make, make install.  Lots and lots
> of the following :
> 
>          warning: cast increases required alignment of target type
> 
> as well as some :
> 
> 
> 	 warning: comparison is always false due to limited range of data type
> 
> Q : I *think* the first one is just warning about wasted space, since
> 4-byte words must be aligned on 4-byte boundaries.  Is this true ?

It should not be a problem, since we take care of aligning things
properly.

> and I got the following :
> 
> >  
> >    (1024) Entering System.Threading.Thread::.cctor ()
> >      (1024) Entering System.Collections.Hashtable::.cctor ()
> >        (1024) Entering System.Object::.ctor (0x20bd938 )
> >        (1024) Leaving System.Object::.ctor => 
> >        (1024) Entering System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray ([0x20c16b8] [vt: 0xbffff7b8] )
> >  0x20c3038:	e1a0c00d	mov	ip, sp
[...]
> So it seems that the very first method that actually does something is
> crashing.  I'm a little (?) too clueless to debug this situation, but
> my question is :

Well, the method that crashes is not a normal method: it's an
internalcall and requires some asm support code to call the C function
that implements it.

> Q: Should mint be close to running on the StrongARM (or any ARM) or is
> there still lots of work to be done ?
> 
> If there is a simple fix to get mint working, I'd love to hear about
> it.

The fix to get the sample working may be simple, but you need to
put yourself in debug mode and learn a bit of ARM assembly to track down
the issue:-)
You can start from mono/arch/arm/tramp.c and get mono_create_trampoline()
to support all the method signatures needed to run a basic example.
Unfortunately, the barrier to entry for porters is higher now than it
was a few months ago, since the interp initializes some runtime
subsystems before running the Main() method of a program and that
requires a working trampoline support, at least for some simple methods.
You may also try to remove the call to mono_thread_init (domain);
in interpreter/interp.c and see if you get any further.

lupus

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