From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 10:39:16 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EDC016A41C for ; Mon, 27 Jun 2005 10:39:16 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id D370A43D1D for ; Mon, 27 Jun 2005 10:39:15 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id l1so160737nzf for ; Mon, 27 Jun 2005 03:39:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZhBR9HWriOJ57KGwaXtGaZeP0ghMAhN5AwFuKQevBIS9r4KSCiIlmD1PJDRAbt4KeOdkyoaeaqDoVxBQVi5w4eFjRf8CuVFb2wWg4HuxR5aNJ/WL2EgpuVO0izcfC1Kvmvx6XpgozBRgh+fxeK4SS3CLcjKPlwyTbots/z7oAsc= Received: by 10.36.66.5 with SMTP id o5mr4414082nza; Mon, 27 Jun 2005 03:39:15 -0700 (PDT) Received: by 10.36.68.15 with HTTP; Mon, 27 Jun 2005 03:39:14 -0700 (PDT) Message-ID: <34cb7c84050627033924fcfcc1@mail.gmail.com> Date: Mon, 27 Jun 2005 11:39:14 +0100 From: Peter Edwards To: Martin Cracauer In-Reply-To: <20050623172948.A65811@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> <42B3189E.6030408@portaone.com> <34cb7c8405061716327ca4c6d7@mail.gmail.com> <20050618083026.26238653@Magellan.Leidinger.net> <34cb7c84050618050623db6187@mail.gmail.com> <20050623172948.A65811@cons.org> Cc: Alexander Leidinger , current@freebsd.org Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Edwards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2005 10:39:16 -0000 On 6/23/05, Martin Cracauer wrote: > > > Have you seen Martin Cracauer's mail ("My hacks to make the memory ma= p > > > fit") on emulation@ which deals with the memory map? Maybe it's of he= lp > > > here... > > > > No I hadn't seen them, thanks for the reference. > > These won't help in this case: It's almost the opposite problem. I thin= k. > > Martin's hack leaves a gap between the data segment and the area that > > mmap starts looking in for address space. However, because of the > > format of the wine binary, it's data segment is very high in memory, > > and the area required by wine's mmap actually falls inside it. i.e., > > Martins fix pushes out the starting point for mmap searches, but wine > > needs hit dragged in. >=20 > If this is still a problem, can you be more specific what you would > like to have mapped where? >=20 > I think I can force anything to map anywhere but I know zero about > Win32 or how Wine works. >=20 I'm not sure if you've seen the original message, but the problem arises from a combination of Wine trying to map a windows heap at location 0x80000000, while locating the executable up at 0x77f00000. My Win32/wine foo is also very weak, but I recall from debugging windows code that the address space in that area is reasonably heavily populated. On FreeBSD the gap between the executable's end (where the data segment is) and 0x80000000 range becomes the maximum extent of your heap, because you can't extend the break beyond the mapped 0x80000000 area, which is too small for practical use with Win32 programs, given that malloc() allocates its space via sbrk(). As I said, I'm not particularly strong on Win32 address layout, so I'll defer to the wine authours' choice on what's best for Win32 compatibility. The problem is that they interact badly with our malloc(). I suspect the ideal solution would be for wine to provides it's own version of malloc(), given it is so sensitive to the mechanism used to carve up address space, but malloc() is probably a better thing to hack on than mmap() from the FreeBSD side in this case, removing the dependency on sbrk() for those executables that need it (although my previous hack is obviously woefully inadequate) I'll see if I can roll some more acceptable patches for malloc().