Albert Lee wrote: > Oops, I meant the subject to be: "Prevent library from being mapped > non-contiguously" > > On Sun, 2008-04-27 at 21:01 -0400, Albert Lee wrote: >> Hi, >> >> I'm trying to fix a problem in Wine that is caused by a shared library >> mapping by the dynamic linker. Wine's memory management facility keeps >> track of where some libraries are mapped and assumes they occupy a >> contiguous range of the process address space. >> >> However, in some cases they are not contiguous. In the following >> example, there is a 56K "hole" (containing a single page?) between >> sections of a library at 7FFB0000. >> >> 7FF20000 448K r-x-- /export/ws/wine/dlls/ntdll/ntdll.dll.so >> 7FF90000 4K rw--- /export/ws/wine/dlls/ntdll/ntdll.dll.so >> 7FF91000 120K r-x-- /export/ws/wine/dlls/ntdll/ntdll.dll.so >> 7FFB0000 4K rw--- >> 7FFBE000 40K rwx-- /export/ws/wine/dlls/ntdll/ntdll.dll.so >> 7FFC8000 72K rwx-- /export/ws/wine/dlls/ntdll/ntdll.dll.so >> >> The problem is that an mmap after the library is loaded can occupy that >> "hole", which then appears as an overlapping segment to Wine's memory >> management (http://bugs.winehq.org/attachment.cgi?id=12470 ). >> >> What is responsible for this "hole"? Is there a way to prevent it when >> creating the object file for the library?
Hmm, interesting set of mappings. Typically there are two or three mapping for most shared objects: the text segment, the data segment, and possibly a /dev/zero mapping to provide for bss. The segments are laid out at link-edit time based on ABI alignments or mapfile controls. The segments are defined by PT_LOAD program headers (see elfdump -p). The runtime linker (ld.so.1) determines the address range required to capture all the files segments, and asks the kernel for enough VM to provide this address range (ie. mmap(0, ..). ld.so.1 then maps the text, data and if necessary, any bss segment to the the appropriate areas within this memory reservation. Any free space between the segments is unmapped. These free spaces could be used to provide for other mmap() requests as the kernel sees fit. Bottom line, ld.so.1 doesn't control where the original total reservation is made, nor what happens to any holes in that reservation that can be freed up. I don't have a copy of this dependency, so I can't see from the ELF program headers how you've gotten 5 separate mappings. Why does Wine need to care where dependencies are mapped? Why does any application care where dependencies are mapped :-) -- Rod.
