Wine needs some mmap improvements

[AndreH]

rev. 44678 in VirtualBox

As Wine code occasionally relies on the Linux behaviour, e.g. to be able to map non-relocatable PE executables to their proper start addresses, or to map the DOS memory to 0, we need some mmap [3] changes on Haiku to give Wine a chance to run.

I attached a strace log that shows what's happening when you try to run Wine. Wine wants to mmap 0x7ffe0000 with reserve_area [1] and get's pointers back like 0x80000000 or 0x00002305.

So what we need from Haiku is MAP_TRYFIXED and some free memory areas. i'd say we are talking about: 0x00000000-0x00010000 (maybe) 0x00110000-0x40000000 0x7ffe0000-0x80000000 and most likely more

We are lucky here, with BeOS it didn't work as the kernel was in the lower space, Haiku doesn't do this, that's great. I've put some information together at [2] and i'll try to get as much changes into upstream Wine to let it run on Haiku. Still i kindly ask you to do something about this bug, otherwise i can't argue to get my changes in.

[1] ​http://source.winehq.org/git/wine.git/blob/479b7bcf604f40929b1f600f31f8d7dfc8b6c991:/libs/wine/mmap.c#l251 [2] ​http://wiki.winehq.org/Haiku [3] ​http://code.metager.de/source/xref/haiku/src/system/libroot/posix/sys/mman.cpp#89

[AndreH]

strace loader/wine cmd

[bonefish]

You're misinterpreting the strace output. _kern_map_file() does not return an address, but an area ID or error code (i.e. the first two calls fail). The address is passed back via the address reference parameter, so unfortunately it doesn't appear in the output (nor does the address hint passed in via the same parameter).

Regarding your mention of MAP_TRYFIXED, my Linux mmap() man page doesn't show such a flag. So I wonder how Wine could require it. Guessing from its name what it might do -- fail, if the address hint could not be heeded -- that shouldn't be too hard to implement, but it can easily be emulated by using mmap() without further flags and checking whether the allocated address was the one passed in.

I'm not entirely sure, what you're asking with respect to "some free memory areas". Not use those ranges? The second one you list covers almost half of the userland address space.

[X512]

Replying to AndreH:

As Wine code occasionally relies on the Linux behaviour, e.g. to be able to map non-relocatable PE executables to their proper start addresses, or to map the DOS memory to 0, we need some mmap [3] changes on Haiku to give Wine a chance to run.

Does PE executables with relocation information already loading correctly? Can you provide patches for building Wine on Haiku?

[AndreH]

hack to compile Wine on Haiku

[AndreH]

Oops, MAP_TRYFIXED seems to be netbsd, i got confused. So ok, lets talk about 0x7ffe0000-0x80000000 first, why is it failing? the returned code seems to be B_NO_MEMORY. Is it to close to the kernel, or is there sitting something else?

I attached a hack to compile Wine on Haiku. ​http://wiki.winehq.org/Haiku has some more instructions and you will need LDFLAGS="-lnetwork" for some dlls. relocating PEs works, still it needs to be in a specific area.

[bonefish]

Replying to AndreH:

So ok, lets talk about 0x7ffe0000-0x80000000 first, why is it failing? the returned code seems to be B_NO_MEMORY. Is it to close to the kernel, or is there sitting something else?

​http://cgit.haiku-os.org/haiku/tree/headers/private/kernel/arch/x86/arch_kernel.h#n65

[AndreH]

Replying to bonefish:

Replying to AndreH:

So ok, lets talk about 0x7ffe0000-0x80000000 first, why is it failing? the returned code seems to be B_NO_MEMORY. Is it to close to the kernel, or is there sitting something else?

​http://cgit.haiku-os.org/haiku/tree/headers/private/kernel/arch/x86/arch_kernel.h#n65

Uuh, that's bad. I'll try to compile Haiku without that limitation to see if that's the only memory issue. Then we can discuss if there's something we can do about it.

[siarzhuk]

By the way, I know some guy with nick 'shade' that digged into porting Wine some time ago. His repo is at ​https://gitorious.org/wine-haiku. Sometime he visit haiku developers channel on irc. As far as I know he is still interested in continueing with Wine but has some problems with Thread Environment Block that has not solve. How can he contact you?

PS: I'm sorry for off-topic, guys.

[AndreH]

strace loader/wine cmd

[AndreH]

As you can see in strace2.txt Wine tries to mmap 0x110000 and Haiku returns 0x453000 for quite a while, how can i see what is sitting under 0x453000 in memory at this moment?

Replying to siarzhuk:

By the way, I know some guy with nick 'shade' that digged into porting Wine some time ago. His repo is at ​https://gitorious.org/wine-haiku. Sometime he visit haiku developers channel on irc. As far as I know he is still interested in continueing with Wine but has some problems with Thread Environment Block that has not solve. How can he contact you?

when i'm online i'm often at #winehackers as Andre_H. Per email: nerv ät dawncrow döt de thx for the hint, i just checked his repo, that way it has no chance to run in current haiku, but i'll have a look again at the winebuild problem and his solution

[bonefish]

Replying to AndreH:

As you can see in strace2.txt Wine tries to mmap 0x110000 and Haiku returns 0x453000 for quite a while, how can i see what is sitting under 0x453000 in memory at this moment?

For x86 the user address space layout is generally the following:

0x00000000 - 0x00100000 Reserved, only allocated upon explicit request.
0x00100000 - 0x18000000 Free range for general area allocations. The kernel maps the
                        runtime loader into this range, the runtime loader creates
                        its small heap here, and executable and libraries are
                        generally mapped here as well.
0x18000000 - 0x48000000 Heap (pre-reserved). General area allocations will start
                        using the unused part of this range once other free ranges
                        have been exhausted.
0x48000000 - 0x6fff0000 Free range for general area allocations.
0x6fff0000 - 0x70000000 Used for kernel-userland communication.
0x70000000 - 0x7efef000 Pre-reserved for thread stacks.
0x7efef000 - 0x7fff0000 main thread stack
0x7fff0000              userland address space top

You an use the listarea command to see the actually allocated. From within your program you can use get_next_area_info() to iterate through your team's areas. The runtime loader is mapped to 0x100000, the executable usually to 0x200000, and libraries somewhere in that range as well.

[AndreH]

thx, here is the listarea part for "wine cmd" breaking in main() from loader/wine. This list easily shows the problems, i have to think about it some more.

   ID                             name   address     size   alloc. #-cow  #-in #-out
------------------------------------------------------------------------------------
 5791            runtime_loader_seg0ro  00100000    14000        0     0     0     0
 5792            runtime_loader_seg1rw  00114000     1000     1000     0     0     0
 5793              runtime_loader_bss1  00115000     1000        0     0     0     0
 5794                         rld heap  00116000    10000     3000     0     0     0
 5795                      _rld_debug_  00126000     1000     1000     0     0     0
 5796                      wine_seg0ro  00200000     1000     1000     0     0     0
 5797                      wine_seg1rw  00201000     2000     2000     0     0     0
 5798            libwine.so.1.0_seg0ro  00203000   12a000        0     0     0     0
 5799            libwine.so.1.0_seg1rw  0032d000     4000     3000     0     0     0
 5800            libwine.so.1.0_seg2rw  00331000    13000        0     0     0     0
 5801                libroot.so_seg0ro  00344000    c5000     5000     0     0     0
 5802                libroot.so_seg1rw  00409000    12000    12000     0     0     0
 5803                libroot.so_seg2rw  0041b000    38000     7000     0     0     0
 5804                             heap  18000000    40000    2c000     0     0     0
 5789                        user area  6fff0000     4000     4000     0     0     0
 5790                   wine_223_stack  7efee000  1002000     4000     0     0     0

[korli]

is this still a problem?

[austin987]

I haven't tested myself, but a recent forum post suggests that it's still an issue (but they've got a semi-working port): ​https://discuss.haiku-os.org/t/my-progress-in-porting-wine/11741

[korli]

To me it seems unrelated to the issue reported.