On Saturday 22 July 2006 19:14, Michael Nottebrock wrote: > WINE does have certain requirements regarding memory allocation. In > particular it (or Windows, rather) really wants a few memory ranges > for itself: > > (from wine-0.9.17/loader/preloader.c): > > * 0x00000000 - 0x00110000 the DOS area > * 0x80000000 - 0x81000000 the shared heap > * ??? - ??? the PE binary load address (usually > starting at 0x00400000) > > The first two are particularly important for WINE running in win98 > (or earlier) emulation mode, which is currently completely broken on > FreeBSD, since those two memory ranges tend to be unavailable.
The reason for the second range is that wine is located way at the end of the 2G range (0x7bf00000). FreeBSD's mmap preserves heap space after that (for brk(2) style allocations). This is about 512Mb by default so everything in 0x7bf00000-0x9bf00000 is unavailable (unless MAP_FIXED is used of course). The DOS area should be available but can't be allocated by wine because of a FreeBSD specific quirk in its code to work arround another mmap related problem. Both problems can be solved by locating wine at say 0x20000000 instead of 0x7bf00000. That leaves plenty of space for the windows executable and allows us to remove mmap related freebsd quirks from wine's code. I've attached two patches that accomplish this, but this seems to trigger other problems, so use at your own risk. If you want to try them, place them in the port's files/ directory and add a line containing "USE_AUTOTOOLS= autoconf:259" to the Makefile. This seems to break wine+libpthread, so I've also changed the port to use libthr instead. For the libpthread experts, I haven't investigated that much further yet, but libpthread seems to fail in create_stack() from _pthread_create() from _thr_start_sig_daemon(). > The preloader bit from which this is quoted is WINE's "own shared > object loader that reserves memory that is important to Wine, and > then loads the main binary and its ELF interpreter", and obviously > does not work right on FreeBSD. I'm not sure whether it can be made > to or not, perhaps somebody familiar with both our VM and runtime > linker could take a look. The preloader isn't used on FreeBSD. You either run wine-kthread or wine(-pthread) directly. The reason for the preloader in linux is mainly exec-shield which makes the mapping of DSOs unpredictable. > http://bugs.winehq.org/show_bug.cgi?id=5732 Do the above mentioned patches solve your second issue here (PE exec location)? > The other big issue with WINE on FreeBSD seems to be our threading > support. WINE quite reliably manages to confuse libpthread, see > http://www.freebsd.org/cgi/query-pr.cgi?pr=threads/100701. On SMP > machines, I've even been able to trigger kernel panics with WINE (in > win2k+ emulation mode) by merely hitting the close button on a > windows application (and WINE subsequently shutting down): > http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/026219.html. > > WINE's threads interface can be found in loader/pthread.c and > loader/kthread.c - again, it would be great, if someone to whom that > sort of code means more than just random gibberish could take a look. Wine does some freaky stack manipulations. I think that may interfere with the way our threading libs handle the stack (allocation etc.). But I am just guessing here really.
--- configure.ac.orig Mon Jul 10 18:01:07 2006
+++ configure.ac Mon Jul 24 15:42:41 2006
@@ -149,7 +149,7 @@
dnl Check for -lresolv for Mac OS X/Darwin
AC_CHECK_LIB(resolv,res_9_init)
dnl Check for -lpthread
-AC_CHECK_LIB(pthread,pthread_create,AC_SUBST(LIBPTHREAD,"-lpthread"))
+AC_CHECK_LIB(thr,pthread_create,AC_SUBST(LIBPTHREAD,"-lthr"))
AC_SUBST(XLIB,"")
AC_SUBST(XFILES,"")
@@ -1116,18 +1116,18 @@
ac_cv_ld_rpath="yes",ac_cv_ld_rpath="no")])
if test "$ac_cv_ld_rpath" = "yes"
then
- AC_SUBST(LDEXERPATH,["-Wl,--rpath,\\\$\$ORIGIN/\`\$(RELPATH)
\$(bindir) \$(libdir)\`"])
- AC_SUBST(LDDLLRPATH,["-Wl,--rpath,\\\$\$ORIGIN/\`\$(RELPATH)
\$(dlldir) \$(libdir)\`"])
+ AC_SUBST(LDEXERPATH,["-Wl,--rpath,${libdir}"])
+ AC_SUBST(LDDLLRPATH,["-Wl,--rpath,${libdir}"])
fi
case $host_cpu in
*i[[3456789]]86* | x86_64)
- AC_CACHE_CHECK([whether we can relocate the executable to
0x7bf00000], ac_cv_ld_reloc_exec,
- [WINE_TRY_CFLAGS([-Wl,--section-start,.interp=0x7bf00400],
+ AC_CACHE_CHECK([whether we can relocate the executable to
0x20000000], ac_cv_ld_reloc_exec,
+ [WINE_TRY_CFLAGS([-Wl,--section-start,.interp=0x20000400],
ac_cv_ld_reloc_exec="yes",
ac_cv_ld_reloc_exec="no")])
if test "$ac_cv_ld_reloc_exec" = "yes"
then
- LDEXECFLAGS="$LDEXECFLAGS -Wl,--section-start,.interp=0x7bf00400"
+ LDEXECFLAGS="$LDEXECFLAGS -Wl,--section-start,.interp=0x20000400"
fi
;;
esac
--- libs/wine/mmap.c.orig Mon Jul 24 11:12:42 2006
+++ libs/wine/mmap.c Mon Jul 24 11:13:39 2006
@@ -200,11 +200,6 @@
if (!(flags & MAP_FIXED))
{
-#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
- /* Even FreeBSD 5.3 does not properly support NULL here. */
- if( start == NULL ) start = (void *)0x110000;
-#endif
-
#ifdef MAP_TRYFIXED
/* If available, this will attempt a fixed mapping in-kernel */
flags |= MAP_TRYFIXED;
@@ -318,7 +313,7 @@
{
struct reserved_area *area;
struct list *ptr;
-#if defined(__i386__) && !defined(__FreeBSD__) && !defined(__FreeBSD_kernel__)
/* commented out until FreeBSD gets fixed */
+#if defined(__i386__)
char stack;
char * const stack_ptr = &stack;
char *user_space_limit = (char *)0x7ffe0000;
pgpwGNgJbSyCi.pgp
Description: PGP signature
