On Mon, 2008-04-28 at 10:39 -0700, Rod Evans wrote: > 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. >
http://trisk.acm.jhu.edu/ntdll.dll.so.gz is a copy. > Why does Wine need to care where dependencies are mapped? Why does > any application care where dependencies are mapped :-) > > Wine does some black magic to make the dependencies palatable to Windows PE executables, to allow importing functions from the dependency as if it were another PE file. -Albert
