<div dir="ltr">Hi,<div><br></div><div>  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 ?</div><div><br></div><div>            Zoltan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 6:02 AM, Ben Carter <span dir="ltr"><<a href="mailto:benml@saillune.net" target="_blank">benml@saillune.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
 Hi,<br>
<br>
 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_<u></u>trampoline() fires. This seems to be a result of this code:<br>
<br>
if ((((guint64)addr) >> 32) == 0)<br>
        buf_len = 16;<br>
else<br>
        buf_len = 30;<br>
<br>
...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.<br>
<br>
 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.<br>
<br>
 Specifically, what I think is happening there is that mono_arch_create_specific_<u></u>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.<br>
<br>
 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.<br>
<br>
 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?<br>
<br>
 Thanks for any ideas or advice!<span class="HOEnZb"><font color="#888888"><br>
-- <br>
 Ben Carter - <a href="mailto:ben@saillune.net" target="_blank">ben@saillune.net</a><br>
______________________________<u></u>_________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.<u></u>com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/<u></u>mailman/listinfo/mono-devel-<u></u>list</a><br>
</font></span></blockquote></div><br></div>