Re: [Mono-dev] Possible bugs in tramp-amd64.c when addresses span 4Gb boundary

2014-09-25 Thread Ben Carter
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, an

Re: [Mono-dev] Possible bugs in tramp-amd64.c when addresses span 4Gb boundary

2014-09-23 Thread Ben Carter
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 pe

Re: [Mono-dev] Possible bugs in tramp-amd64.c when addresses span 4Gb boundary

2014-09-23 Thread Zoltan Varga
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 ? Zoltan On Tue, Sep 23, 2014 at 6:02 AM, Ben Carter wrote: > > Hi, > > I've been looking into a bug that I've encountered running M

[Mono-dev] Possible bugs in tramp-amd64.c when addresses span 4Gb boundary

2014-09-23 Thread Ben Carter
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_