Date: Sun, 24 Oct 2004 15:48:26 -0400 (EDT) From: Anish Mistry <amistry@am-productions.biz> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/73092: Unbreak WINE for 5.x and 6 Message-ID: <200410241948.i9OJmQDb058926@www.united-ware.com> Resent-Message-ID: <200410242010.i9OKAAW1058134@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 73092
>Category: kern
>Synopsis: Unbreak WINE for 5.x and 6
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Oct 24 20:10:10 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator: Anish Mistry
>Release: FreeBSD 5.3-BETA7 i386
>Organization:
AM Productions
>Environment:
System: FreeBSD bigguy.am-productions.biz 5.3-BETA7 FreeBSD 5.3-BETA7 #5: Fri Oct 22 18:29:32 EDT 2004 amistry@bigguy.am-productions.biz:/usr/obj/usr/src/sys/BIGGUY i386
>Description:
Versions of WINE after May 2004 no longer work with FreeBSD. This is
due to WINE being unable to mmap part of the process address space to load in
the Windows executables. The reason this happens is because FreeBSD only allows
anonymously mmaping the upper part of the process address space after the
reserved data sections.
>How-To-Repeat:
Build a version of WINE after May 2004 and try to run a program.
>Fix:
The attached patch for vm_mmap.c will allow the mmap() syscall to be
able to anonymously mmap free areas of the process address space below the
reserved area. The wine mmap.c patch removes the reserving of the DOS area
thus allowing the correct executable load location to be used.
--- wine-mmap.patch begins here ---
--- libs/wine/mmap.c.orig Mon Sep 6 01:23:40 2004
+++ libs/wine/mmap.c Mon Sep 6 01:23:46 2004
@@ -294,7 +294,7 @@
area = LIST_ENTRY( ptr, struct reserved_area, entry );
if (!area->base) return;
}
- reserve_dos_area();
+ /*reserve_dos_area();*/
}
#else /* HAVE_MMAP */
--- wine-mmap.patch ends here ---
--- vm_mmap-wine-6-current.patch begins here ---
--- vm_mmap.c.orig Thu Aug 5 03:04:33 2004
+++ vm_mmap.c Wed Aug 18 21:31:13 2004
@@ -208,6 +208,8 @@
vm_offset_t addr;
vm_size_t size, pageoff;
vm_prot_t prot, maxprot;
+ vm_map_t map;
+
void *handle;
int flags, error;
off_t pos;
@@ -276,9 +278,26 @@
if (addr == 0 ||
(addr >= round_page((vm_offset_t)vms->vm_taddr) &&
addr < round_page((vm_offset_t)vms->vm_daddr +
- lim_max(td->td_proc, RLIMIT_DATA))))
+ lim_max(td->td_proc, RLIMIT_DATA)))) {
+ /*
+ * XXX So much dirtyness someone who knows what they are doing
+ * will want to fix this monstrosity.
+ */
+ map = &td->td_proc->p_vmspace->vm_map;
+ vm_map_lock(map);
addr = round_page((vm_offset_t)vms->vm_daddr +
- lim_max(td->td_proc, RLIMIT_DATA));
+ lim_max(td->td_proc, RLIMIT_DATA));
+ if(vm_map_findspace(map, addr, size, &addr) != 0) {
+ /*
+ * since we can't grab the upper process address space bruteforce it.
+ */
+ for(addr = 0;addr <= round_page((vm_offset_t)vms->vm_taddr) &&
+ vm_map_findspace(map, addr, size, &addr) != 0
+ ;addr += PAGE_SIZE,addr = round_page(addr));
+ }
+ vm_map_unlock(map);
+ }
+
PROC_UNLOCK(td->td_proc);
}
if (flags & MAP_ANON) {
--- vm_mmap-wine-6-current.patch ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410241948.i9OJmQDb058926>