/* Try to allocate code chunks next to each other to help the VM */ ptr = NULL; if (last) ptr = codechunk_valloc ((guint8*)last->data + last->size, chunk_size); if (!ptr) ptr = codechunk_valloc (NULL, chunk_size); if (!ptr) return NULL;
The kernel virtual memory manager or the Mono virtual machine?
The kernel virtual memory manager surely will help itself most with NULL there.
I imagine it is the map32bit stuff for amd64, so the Mono virtual machine.
Comments should/could be clearer imho.
As well, only systems that use the map32bit stuff should have this logic, I think.
arm/mips/powerpc, why the 32bit here?
ss_trigger_page = mono_valloc (NULL, mono_pagesize (), MONO_MMAP_READ|MONO_MMAP_32BIT, MONO_MEM_ACCOUNT_OTHER); bp_trigger_page = mono_valloc (NULL, mono_pagesize (), MONO_MMAP_READ|MONO_MMAP_32BIT, MONO_MEM_ACCOUNT_OTHER);
I assume mips implies 32bit.
I know arm does (arm64 is separate).
PowerPC I guess was dual purpose, but is now 64bit only?, so it seems the only user like this (I know amd64 has a different use).
On Windows there could be some hypothetical creation of a truncatable address,
for a 32bit debugger to poke at a 64bit target. Or to push the address
over a transport that truncates to 32bits even if to a 64bit target.
But mono does not target Windows with these architectures (it did/does run on them!).
But still, it is only for powerpc64 seemingly.
trusson the system, yes?
root@teldrassil:/usr/ports/lang/mono6.0 # ldd /usr/local/bin/mono /usr/local/bin/mono: libz.so.6 => /lib/libz.so.6 (0x8006b5000) libutil.so.9 => /lib/libutil.so.9 (0x8006cf000) libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x8006e6000) libm.so.5 => /lib/libm.so.5 (0x8007e4000) libinotify.so.0 => /usr/local/lib/libinotify.so.0 (0x800816000) libthr.so.3 => /lib/libthr.so.3 (0x800821000) libc.so.7 => /lib/libc.so.7 (0x80084c000)
-lexecinfois enough for now