|
From: John R.
|
Looking at the wine preloader's travails with reserving address space, including http://www.nabble.com/Valgrind-and-Wine-td14442642.html , here are some thoughts. Julian's comment about changing valt_load_address_normal certainly is part of the solution. Try 0x60000000 (1.6GB) as the value, to allow for some large Win32 programs. Regarding R.Walsh's comment about building the Wine preloader into Valgrind, there may be a shortcut. Create a new global variable minimum_mmap_address, default to 0 but use 0x60000000 (1.6GB) for wine, then do mmap(minimum_mmap_address, ...) instead of mmap(0, ...) . This causes the Linux kernel to start its ascending search for a suitable place in the address space at minimum_mmap_address instead of 0. Of course this is necessary for all non-tracked mmap, including calls from ld-linux and glibc internals used by the valgrind core and the tool. Mapping of a pre-linked .so also must use mmap(minimum_mmap_address, ...) instead of mmap(pre_linked_address, ...) According to the source wine/loader/preloader.c , the sacred ranges are: * 0x00000000 - 0x00110000 the DOS area * 0x80000000 - 0x81000000 the shared heap * ??? - ??? the PE binary load address (usually starting at 0x00400000) The DOS area and PE binary load address is covered by minimum_mmap_address. The preloader takes care of the shared heap area by reserving 0x02000000 bytes at 0x7f000000. So this would be a new global variable in ld-linux and glibc. The technical change would not be hard, and other "embedded" projects (in addition to wine) might applaud. But the existing maintainers of glibc probably would resist. -- John Reiser, jreiser@BitWagon.com |