[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Upcoming breakage warning
From:       Robert Lunnon <bobl () optushome ! com ! au>
Date:       2004-05-29 10:46:31
Message-ID: 200405292046.31579.bobl () optushome ! com ! au
[Download RAW message or body]

On Fri, 21 May 2004 12:58 am, Francois Gouget wrote:
> On Thu, 20 May 2004, Mike Hearn wrote:
> [...]
>
> > This is no longer true. According to a Red Hat kernel engineer, you can
> > use "setarch i386 wine ...." to switch it back to the 3/1 split while we
> > fix it in the Wine code.
>
> Don't we have the same problem with the 3/1 split?
> If I remember correctly we can get into trouble if anything gets loaded
> above the 2G mark, depends on the application.

As one who has been bitten by this for several years I can say that many 
(Most) windows apps dont care where their pointers point. Simply changing 
ADDRESS_SPACE_LIMIT does  actually work in many cases and making this 
configurable will make wine usable in these environment even if it breaks 
some naughty applications that depend on the 3G/1G split!!

From my recollection this limit is only tested for heap allocation which is 
specifically provided by and anonymous mmap, presumably for performance 
purposes.

The proposed solution for this has been to prevent mmap from allocating over 
the 3GB mark by reserving any free space over that limit with a chain of mmap 
calls.

At least under Solaris there would appear to be  two other "nicer" ways to 
achieve the same result.

1. Allocate the windows heap with a call to libc malloc which at least under 
Solaris maps memory from the stack top upward in memory.

2. For each mmap call locate a suitable unmapped memory area and then mmap 
FIXED that area, a technique already used successfully in the Solaris 
specific mmap code.

Of course none of this will prevent DSOs being loaded above the top of memory 
but. from the wine codebase only the heap seems to be at issue.


For what it's worth I can't see Microsoft retaining this architecture since 
the windows split is not likely to be the same into the future for example 
with AMD64 and probably was different even for Alpha. I also acknowledge that 
Alexandre and I disagree on this particular point.

Bob


[prev in list] [next in list] [prev in thread] [next in thread]