[Bug 16023] PC-BSD fails to launch majority of applcations, 'Invalid address'

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=16023





--- Comment #20 from Tijl Coosemans <tijl at ulyssis.org>  2008-12-27 11:26:11 ---
I wrote down a few things to get a bit of an overview. If there's anything
wrong or if something can be done differently please say so.

These are the things related to mmap:
* location of executables, DSOs (*.dll.so *.exe.so, *.so)
* thread stacks
* malloc heap spaces

These are the things outside wine that use mmap:
* ELF loader calls mmap syscall directly.
* libc malloc calls internal libc mmap.
* DSOs can call libc mmap(2), but could also call the syscall.
* Stack allocation by libpthread. Inside Wine, stack allocation can be
controlled by setting thread attributes in the argument to pthread_create(3),
but threads could be created in code outside Wine as well.

Different mmap implementations:
* Allocate from the main stack downwards. (Linux)
* Allocate from the program start address+malloc heap upwards. (*BSD)
* Allocate randomly. (SELinux?)

Other observations:
* Wine wants to control at least the lower 2GiB of address space, but
preferably even more to support 3GiB aware processes (?).
* Some .dll.so files have a specific image base address, and all of them are
best allocated below 0x80000000 (at least for processes that aren't 3GiB
aware).
* Most ELF loaders don't support base addresses for DSOs. AFAIK only the glibc
loader in combination with prelink. (It's possible that linking DSOs as an ELF
executable type can trick some loaders into supporting it, but this isn't
portable.)
* At thread creation/destruction libpthread calls into the ELF loader to
allocate/deallocate thread local storage for symbols that have been declared
with __thread. These functions are essentially private and OS specific.

Consequences:
* You can't control all mmap calls (for instance by overriding/wrapping the
libc mmap symbol).
* To support the random mmap you need something like wine-preloader which
preserves all the regions Wine wants to control before any DSO ends up there.
* To support .exe.so and .dll.so base addresses Wine needs its own ELF loader
or a .exe.so/.dll.so loader as a wrapper around the OS ELF loader.
* If Wine has its own .dll.so loader anyway it can make sure they all end up
below 0x80000000 independent of the OS ELF loader capabilities and mmap
implementations.
* The Wine loader (wine-pthread/kthread) could then be located at around
0xa0000000 for instance instead of 0x7bf00000 now, leaving plenty of space up
to the main stack for all mmap calls outside Wine.
* Everything before the Wine loader can be preserved by wine-preloader and can
be used by the Windows process. Wine would keep track of used/free regions and
always call mmap with a specific address and MAP_FIXED. Beware of multiple
threads here. Never call munmap.

About the .exe.so/.dll.so loader:
* Because libpthread calls into the OS ELF loader, that one will still have to
be around and to support __thread symbols in code outside Wine all standard .so
libraries need to be loaded by it.
* So, any dependencies that are standard .so libraries would have to be loaded
using the dlopen/dlclose/dlsym API.
* If __thread is used in .dll.so or .exe.so, Wine needs to wrap thread
creation/destruction to call into the .dll.so loader which can
allocate/deallocate the memory for those symbols.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.