Re: [Mono-dev] Possible bugs in tramp-amd64.c when addresses span 4Gb boundary
On 24/09/2014 10:34 am, Ben Carter wrote: On 24/09/2014 02:22 am, Zoltan Varga wrote: Hi, Mono tries to allocate all its code into the lower 32 bit part of the address space (see MAP_32BIT in mono-codeman.c). What platform is this ? Ah, that might well explain it - this is on Windows, and as far as I can see there's no code to perform an equivalent limiting of the allocated address ranges. This is starting to make sense now... Just as a quick follow-up in case anyone else runs into this - Zoltan was absolutely right. The issue was that MONO_ARCH_NOMAP32BIT was not set (meaning that the JIT was assuming that all code would be in the lower 32 bit region), but the corresponding code to implement the MAP32BIT flag in the allocator didn't exist. Thus, setting MONO_ARCH_NOMAP32BIT has fixed everything (as far as I can tell!). Thanks again! -- Ben Carter - b...@saillune.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Possible bugs in tramp-amd64.c when addresses span 4Gb boundary
On 24/09/2014 02:22 am, Zoltan Varga wrote: Hi, Mono tries to allocate all its code into the lower 32 bit part of the address space (see MAP_32BIT in mono-codeman.c). What platform is this ? Ah, that might well explain it - this is on Windows, and as far as I can see there's no code to perform an equivalent limiting of the allocated address ranges. This is starting to make sense now... Thanks! -- Ben Carter - b...@saillune.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Possible bugs in tramp-amd64.c when addresses span 4Gb boundary
Hi, I've been looking into a bug that I've encountered running Mono on a 64-bit x86 system - specifically, where the "((code - start) < buf_len)" assert in mono_arch_get_static_rgctx_trampoline() fires. This seems to be a result of this code: if guint64)addr) >> 32) == 0) buf_len = 16; else buf_len = 30; ...which assumes that if the destination address is <4Gb then a 32-bit jump will be used, which isn't true if the code being generated is more than ~2Gb away. Looking further into this, I found that this pattern appears elsewhere in tramp-amd64.c as well - and may explain another problem I've been seeing where trampolines get "randomly" corrupted to point to nonsensical addresses. Specifically, what I think is happening there is that mono_arch_create_specific_trampoline() is creating the trampoline, and that at the time of creation the target address is within a 32-bit jump from the source, so it generates a regular 32-bit CALL. However, mono_arch_patch_callsite() appears to only check for the target address being >4Gb when patching, meaning that it can (as far as I can see) end up doing a 32-bit InterlockedExchange() that truncates the offset in the case where the target is too far away. This would then result in what I'm seeing, which is that the trampoline code is well-formed by the target of the CALL is non-executable memory with nothing in it. Does this sound like a reasonable hypothesis? Or is there something that I'm missing about how trampolines operate that means that offsets of this nature shouldn't occur in the first place? Thanks for any ideas or advice! -- Ben Carter - b...@saillune.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono on PowerPC-64
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 - b...@saillune.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Best practices for porting Mono, and a couple of questions
Hi, I'm new to this ML, so I hope that this isn't an FAQ or anything, but searching the archives didn't turn up much in the way of answers so fingers crossed... I'm currently looking into porting Mono to an ARM-based embedded system that sadly doesn't have much of a POSIX layer. Therefore, as far as I can tell, there are three main areas of the code that I need to touch (leaving ABI stuff off to one side for the moment): 1) eglib 2) pthreads (since it's used in lots of places, it seems easier to write a pthreads-compatible wrapper than try to change the code to use the native threading API) 3) io-layer Now, the first couple of those are fairly straightforward, but the third has me a little confused - specifically, the current io-layer seems to be a mix of support code for various OSes (Win32, Linux and OSX, primarily) with #ifdefs to sort it all out. However, that is presumably because those all share enough common posix-base code that the advantages of keeping them together outweigh the disadvantages... Thus, for this new system, my instinct is that I should be creating an entirely new io-layer directory and writing all the necessary code there. However, I can't see any obvious way to switch the build process over to using an alternative directory (other than replacing the existing one)... is there something I've missed that allows swapping OSes within a single source tree, or is the assumption that each OS should have its own branch with a unique copy of io-layer? (or am I barking up the wrong tree entirely here... would it be simpler to write some posix emulation wrapper code in the same way that I'm handling pthreads?) On a slightly different topic, I found a post from a few years back about porting Mono to a new OS (http://www.skyos.org/?q=node/464) that mentions mmap being a requirement. Thus far I've yet to spot anything in the current source code that looks like it would fail critically without mmap, but again I could be missing it entirely - does anyone know if lack of it will cause insurmountable problems? Any information on these or indeed advice on porting strategy in general would be very gratefully received - many thanks in advance! -- Ben Carter - b...@saillune.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
