Muli Ben-Yehuda wrote:
>On Tue, Dec 27, 2005 at 02:46:59PM +0200, Rafi Gordon wrote:
>
>
>
>>I was wondering in which occasions is this
>>system call being invoked: did anybody had encountered (or used himeslf)
>>a call to modify_ldt() in other apps (emulators maybe ? ).
>>
>>
>
>qemu uses it:
>
>"The Linux system call modify_ldt() is used to create x86 selectors to
>test some 16 bit addressing and 32 bit with segmentation cases."
>
>I assume that wine uses is for similar reasons, but haven't checked.
>
>
I'm a bit out of touch with wine lately, and no one is really in-touch
with this particular area but Alexandre, but I can venture a guess. Wine
does everything it can (and one or two things it, according to any
standard measure, can't) to create a work (read - memory map)
environment that is the same as the one used by Windows. In Windows (as
in some Linux programs), DLLs have means to be loaded in different
addresses than those under which they were compiled, but standard
executeables do not. Also, some copy-protection scheme end up assuming
certain things about the memory address in which each program component
is loaded.
The ultimate upshot of all of the above is that Wine jumps throgh hoops
trying to make sure that the memory image under Linux is the same as the
memory image under Windows for loaded programs. I will not be the least
surprised if the above call has something to do with it.
As a side note, there (at least used to be) some bugs relating to
interactions between the Linux memory allocator and the way Wine loads
itself. The most annoying one is this. Under Linux (assuming 32 bit
Intel machine), the first 3GB of virtual address space are free for
program use. The last 1GB is used by the kernel. This is called a 3/1
split. Under Windows, it is most common to have a 2/2 split. For that
reason, Wine eliminates the entire upper half of the virtual address
space from being allocated to the program.
It gets worse, however. Under Linux, the first 1GB is treated
differently from the rest of the memory. It is typically where the
program's heap is stored. In order to avoid fragmentation of the
program's heap, Linux keeps mmap allocated memory from being allocated
from that area. In plain words, at least in the past, mmaps that did not
specifically ask for memory in the lower 1GB of the address space, would
never get such an address. If the rest of the address space is already
allocated, the mmap will simply fail. "malloc" does not use mmap (unless
it has to), and uses "brk" instead, which is allowed to allocate from
the lower 1GB.
Our trouble are not over, however. brk allocates contigous blocks of
memory, starting from where the program is loaded. As I mentioned
earlier, however, Wine plays around with where the program is loaded, to
match the Windows behaviour. As a result, brk is unable to allocate
memory from the first 1GB of memory when running under Wine. In other
words, a Windows program has 2GB of virtual memory to use, a Linux
program 3, but a Wine program only 1.
I have seen some patches that told mmap to bloody well start allocating
memory from the lower 1GB if the rest of the memory has been exhuasted,
but I don't know whether they made it into the mainstream kernel.
Anticipating your next question - yes, I have had a case where this
actually mattered.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
