[Mono-dev] patch to mono-mman.c to accommodate Android, bug report for Arm thunk handling
Koushik K. Dutta
koush at koushikdutta.com
Tue Jan 20 21:37:39 EST 2009
Hello again!
Android's libc has an implementation of mmap, but does not implement shmem functions. Instead Android uses a different implementation of memory sharing called "ashmem".
mono-mman.c assumes that if mmap is available/implemented, so is shm_open. This change further reorganizes the code so that mmap and and shm_open are uncoupled (as they are not really dependent on each other). This allows Mono on Android to use mmap instead of malloc.
Incidentally, this change came out of necessity: if mmap is not available, Mono falls back to using the malloc based implementation of mono_valloc. The problem with malloc is that it exposed a bug in the Arm thunk handling:
If the delta between the of a branch-and-link and the target's instruction pointer is greater than 0x1ffffff, it will attempt to utilize a thunk to explicitly set the program counter to the target. The problem with this is that the number of entries in the thunk table is hard coded to (code chunk length / 8). So if the intended thunk table fills up due to numerous thunks, it will check the other tables that are available. This is where malloc and mmap seem to behave differently:
* mmap seems to provide sequential memory addresses with every successive call to the function. This works out well, since then the original branch-and-link that is being modified is in branch range of thunk tables that were created for other code chunks.
* malloc , at least on Android, seems to provide wildly different addresses with each successive call (in a deterministic manner it seems). In my case, it starts out providing addresses in the 0x00700000 range. Then the addresses jump up into the 0x40000000 range. This is where if a thunk table fills up, and Mono can't find a suitable thunk slot (one that is in branch range), it fails at the assert in mini-arm.c:handle_thunk:~2035.
So, although this bug exists for any Arm build, this patch just keeps it from surfacing on Android (for now). I looked into actually fixing this properly, because it is possible that it could occur with mmap (it is just very unlikely). But from my investigation, the changes would be too deep (changes to arm_patch, and more). And I'm not familiar enough with the code... yet. :)
Koushik Dutta
www.koushikdutta.com<http://www.koushikdutta.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090120/146bc2c6/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: androidmono.patch
Type: application/octet-stream
Size: 2727 bytes
Desc: androidmono.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090120/146bc2c6/attachment.obj
More information about the Mono-devel-list
mailing list