[Mono-dev] Mono on PowerPC-64

Ben Carter benml at saillune.net
Tue Dec 4 17:14:25 UTC 2012


Hi,

 I'm currently trying to get Mono 2.11.4 running on a PPC64 (ilp32)
system, and I've hit a problem that I'm a bit puzzled by.

 Basically, I'm running an AOT pass on mscorlib (on the target, not
cross-compiling), and when it tries to convert
Microsoft.Win32.KeyHandler:LoadKey(System.Security.SecurityElement) it
hits an assert in mono_spill_global_vars in method_to_ir.c (line 11976
or thereabouts) - specifically in the SREG spilling:

g_assert (var->opcode == OP_REGOFFSET);

...which fails because var->opcode is 328 (OP_LOCAL, as far as I can see)

With the verbose level cranked up, the block it's processing looks like
this:

SPILL BLOCK 30:
 load_membase R215 <- [R32 + 0x10]
	 ii  215 32
	1  load_membase R215 <- [r27 + 0x10]
 checkthis [R33 + 0x0]
	  i  -1 33
	1  checkthis [r28 + 0x0]
 not_null R33
	  i  -1 33
	1  not_null r28
 load_membase R227 <- [R33 + 0x8]
	 ii  227 33
	1  load_membase R227 <- [r28 + 0x8]
 lcall R224 <- [long:Parse (string)] [r3 <- R227] clobbers: c
	 l   224
	1  lcall r24 <- [long:Parse (string)] [r3 <- R227] clobbers: c
 got_entry R230 <- [R46 + 0x0]
	 ii  230 46
	1  got_entry R230 <- [r30 + 0x0]
 call R229 <- [mono_object_new_ptrfree_box] [r3 <- R230] clobbers: c
	 i   229
	1  call R229 <- [mono_object_new_ptrfree_box] [r3 <- R230] clobbers: c
 storei4_membase_reg [R229 + 0x8] <- R226
	  ii -1 226

var is apparently "local R226 <-" if I dump it out.

Now, I'm not particularly familiar with the mono codebase, so I'm having
a bit of trouble figuring out what this means. I'm quite suspicious of
the fact that R226 looks like it isn't actually ever written to anywhere
in the instruction dump I've got - there are several instances where
like this is gets stored out, but unless I've missed something I'm
guessing that it would be normal to expect a "R226 <-" instruction to
appear somewhere to actually load/set it...?

Another bit of weirdness is that this problem doesn't appear if I set
the architecture to PPC32 - doing that allows me to compile the whole
assembly fine and generates a "working" version (which doesn't
/actually/ work, because of the different handling of function pointers
between PPC64 and PPC32, but by eye it looks right).

Does anyone have any suggestions as to what might be going wrong here,
or where I should look next to try and figure out the problem?

 Many thanks in advance!
-- 
 Ben Carter - ben at saillune.net


More information about the Mono-devel-list mailing list