Re: Towards a working "wine". [long]

> >>... 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?

Well, It's definitely behaved that way "traditionally" (where
traditionally means on any platform I've had to use mmap() on), and
the manpage is less than specific about what "cannot be used" means.
SUSv3 has this to say:

> If a MAP_FIXED request is successful, the mapping established by mmap() 
> replaces any previous mappings for the process' pages in the range 
> [pa,pa+len).

Again, it's very hazy, but it at least explicitly mentions that
MAP_FIXED may replace previous mappings.

Really, MAP_TRYFIXED is just a hack to avoid the trouble the kernel
goes to in an effort to avoid mmap() and sbrk() from stomping on
eachother. It doesn't matter in Linux because sbrk() has much less
effect on things. (It's not a sytem call) I'd imagine it better to add
an explicit flag for this corner case than to change the behaviour of
existing applications. Apps using MAP_FIXED already are likely to be
quite sensitive to such a change.