Peter Edwards wrote: > On 6/17/05, Maxim Sobolev <sobomax_at_portaone.com> wrote: > >>Peter Edwards wrote: >> >>>Y'all, >>> >>>I wanted to run a substantial windows app using "wine", and failed >>>miserably. Looking around, it appears to be an acknowledged fact >>>that wine is borked on FreeBSD, so I did some hacking about. >>> >>>The problems I found are centered around address space allocation: >>>Wine is inevitably somewhat sensitive to address space layout, >>>seeing as it has to present the Win32 binaries with a reasonably >>>familiar environment. (All this assumes standard kernel, etc. Fixed >>>addresses are the order of the day) >>> >>>Problem 1: >>> >>>When starting up, Wine needs to mmap stuff at address 0x80000000, >>>but does so without using MAP_FIXED: I think the intention is that >>>the code involved should be "best effort" to map to the hint address >>>supplied to mmap(), rather than an all-or-nothing thing. >>> >>>FreeBSD's mmap sees this as an address in the data segment (see >>>problem 2 below), and shifts the hint along to an address past >>>there. There appears to be a MAP_TRYFIXED flag that wine uses on >>>some systems that affords the hint more weight, which is pretty >>>trivial to implement (see wine_mmap.txt). That was enough to get >>>my app running, but not for long. >> >>Well, there is really no point of adding another MAP_TRYFIXED flag, >>since wine can call mmap(2) with MAP_FIXED and then if that fails try to >>call mmap(2) without it and deal with consequences. This will provide >>the same functionality but you won't get dependency on particular >>FreeBSD version to get MAP_TRYFIXED define. >> > > > Nope: MAP_FIXED will unconditionally overwrite any existing mapping at > the requested address. Hmm, the manpage doesn't mention anything of the effect. It only says: MAP_FIXED Do not permit the system to select a different address than the one specified. If the specified address can- not be used, mmap() will fail. If MAP_FIXED is speci- fied, addr must be a multiple of the pagesize. Use of this option is discouraged. Nothing about "overwriting any existing mapping". So that maybe implementation should be adjusted to match documentation, not another functionality be invented to workaround misbehaving implementation? -MaximReceived on Fri Jun 17 2005 - 16:38:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:37 UTC