FreeBSD prefers to use a 0x200000 (super) page alignment. This causes the image base to be displaced from the requested location. Forcing a smaller page size ensures the image can be placed there.
This should not have negative impact on other, e.g. Linux-based, platforms I believe.
The patch was originally contributed to the FreeBSD emulators/wine(-devel) port by David Naylor in February 2015. We have carried it as part of those two ever since, with occasional adjustments of mine. I am now submitting this here with David's consent.
Signed-off-by: Gerald Pfeifer [email protected] Signed-off-by: David Naylor [email protected], --- dlls/kernel32/Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/kernel32/Makefile.in b/dlls/kernel32/Makefile.in index 832f2365b15..f932f83c6b6 100644 --- a/dlls/kernel32/Makefile.in +++ b/dlls/kernel32/Makefile.in @@ -2,7 +2,7 @@ EXTRADEFS = -D_KERNEL32_ -D_NORMALIZE_ MODULE = kernel32.dll IMPORTLIB = kernel32 IMPORTS = kernelbase ntdll winecrt0 -EXTRADLLFLAGS = -mno-cygwin -nodefaultlibs -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b600000 +EXTRADLLFLAGS = -mno-cygwin -nodefaultlibs -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b600000 -Wl,-z,max-page-size=0x1000
C_SRCS = \ atom.c \
Am 12.11.2020 um 21:58 schrieb Gerald Pfeifer [email protected]:
FreeBSD prefers to use a 0x200000 (super) page alignment. This causes the image base to be displaced from the requested location. Forcing a smaller page size ensures the image can be placed there.
Is kernel32 built as a dll.so without mingw in this case? If it is a PE DLL as it should be then the problem should be fixed in the PE loader I think - it would also affect DLLs shipped by programs etc.
On Fri, 13 Nov 2020, Stefan Dösinger wrote:
Is kernel32 built as a dll.so without mingw in this case? If it is a PE DLL as it should be then the problem should be fixed in the PE loader I think - it would also affect DLLs shipped by programs etc.
Ah, good point. And, yes, the FreeBSD ports don't use MinGW at this point.
(Per Damjan and Alexandre the patch turns out to have been a noop the last while FreeBSD has been carrying it; I'll see to remove it there.)
Thank you, Gerald
On Thu, Nov 12, 2020 at 8:58 PM Gerald Pfeifer [email protected] wrote:
FreeBSD prefers to use a 0x200000 (super) page alignment. This causes the image base to be displaced from the requested location. Forcing a smaller page size ensures the image can be placed there.
This should not have negative impact on other, e.g. Linux-based, platforms I believe.
The patch was originally contributed to the FreeBSD emulators/wine(-devel) port by David Naylor in February 2015. We have carried it as part of those two ever since, with occasional adjustments of mine. I am now submitting this here with David's consent.
Signed-off-by: Gerald Pfeifer [email protected] Signed-off-by: David Naylor [email protected],
dlls/kernel32/Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/kernel32/Makefile.in b/dlls/kernel32/Makefile.in index 832f2365b15..f932f83c6b6 100644 --- a/dlls/kernel32/Makefile.in +++ b/dlls/kernel32/Makefile.in @@ -2,7 +2,7 @@ EXTRADEFS = -D_KERNEL32_ -D_NORMALIZE_ MODULE = kernel32.dll IMPORTLIB = kernel32 IMPORTS = kernelbase ntdll winecrt0 -EXTRADLLFLAGS = -mno-cygwin -nodefaultlibs -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b600000 +EXTRADLLFLAGS = -mno-cygwin -nodefaultlibs -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b600000 -Wl,-z,max-page-size=0x1000
Hi
Is this patch still necessary? It looks like I already have the correct base address for kernel32, on both the ELF build, and my hacked-up PE build (using mingw from Debian running on FreeBSD's Linuxulator).
PE build: $ cat /proc/23365/map | grep kernel32 *0x7b600000* 0x7b601000 1 0 0xfffff8026db42000 r-- 72 27 0x1000 COW NC vnode /compat/i386/usr/home/dj/.local/lib/wine/kernel32.dll CH 1003 0x7b601000 0x7b631000 48 0 0xfffff8026db42000 r-x 72 27 0x1000 COW NC vnode /compat/i386/usr/home/dj/.local/lib/wine/kernel32.dll CH 1003 0x7b631000 0x7b635000 4 0 0xfffff8039bd70900 rw- 1 0 0x3000 COW NNC vnode /compat/i386/usr/home/dj/.local/lib/wine/kernel32.dll CH 1003 0x7b635000 0x7b639000 4 0 0xfffff8026db42000 r-- 72 27 0x1000 COW NC vnode /compat/i386/usr/home/dj/.local/lib/wine/kernel32.dll CH 1003 0x7b63a000 0x7b63b000 1 0 0xfffff800b7497d00 rw- 1 0 0x3000 COW NNC vnode /compat/i386/usr/home/dj/.local/lib/wine/kernel32.dll CH 1003 0x7b63b000 0x7b64a000 14 0 0xfffff8026db42000 r-- 72 27 0x1000 COW NC vnode /compat/i386/usr/home/dj/.local/lib/wine/kernel32.dll CH 1003 0x7b64a000 0x7b6a7000 77 0 0xfffff8038bd8c100 rw- 1 0 0x3000 COW NC vnode /compat/i386/usr/home/dj/.local/lib/wine/kernel32.dll CH 1003 0x7b6a7000 0x7b78c000 213 0 0xfffff8026db42000 r-- 72 27 0x1000 COW NC vnode /compat/i386/usr/home/dj/.local/lib/wine/kernel32.dll CH 1003
ELF build: $ cat /proc/14134/map | grep kernel32 *0x7b600000* 0x7b620000 32 0 0xfffff800a17c1600 r-x 1 0 0x2000 COW NC vnode /compat/i386/usr/home/dj/.local/opt/wine-elf/lib/wine/kernel32.dll.so CH 1003 0x7b621000 0x7b676000 63 0 0xfffff802666dd500 r-x 1 0 0x3000 COW NC vnode /compat/i386/usr/home/dj/.local/opt/wine-elf/lib/wine/kernel32.dll.so CH 1003 0x7b676000 0x7b6de000 104 0 0xfffff802664f8000 rw- 1 0 0x3000 COW NNC vnode /compat/i386/usr/home/dj/.local/opt/wine-elf/lib/wine/kernel32.dll.so CH 1003
Maybe Wine already loads kernel32.dll(.so) at the right base address, after 55ba3648379d90642f174e74809b84130d6d1ddc and e0138c4a6a7a87f1d25badd43e05490e706bc666 fixed mmap() usage on FreeBSD, and/or other recent commits?
Damjan
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=81852
Your paranoid android.
=== debiant (build log) ===
Task: Patch failed to apply
=== debiant (build log) ===
Task: Patch failed to apply
Damjan Jovanovic [email protected] writes:
Maybe Wine already loads kernel32.dll(.so) at the right base address, after 55ba3648379d90642f174e74809b84130d6d1ddc and e0138c4a6a7a87f1d25badd43e05490e706bc666 fixed mmap() usage on FreeBSD, and/or other recent commits?
winegcc passes that flag already, so the patch should make no difference.
On Fri, Nov 13, 2020 at 10:45 PM Alexandre Julliard [email protected] wrote:
Damjan Jovanovic [email protected] writes:
Maybe Wine already loads kernel32.dll(.so) at the right base address, after 55ba3648379d90642f174e74809b84130d6d1ddc and e0138c4a6a7a87f1d25badd43e05490e706bc666 fixed mmap() usage on FreeBSD, and/or other recent commits?
winegcc passes that flag already, so the patch should make no difference.
And has done so since wine-1.9.7:
commit e59395208d527d1bffb2725efc85fb798aee7610 Author: Alexandre Julliard [email protected] Date: Mon Mar 28 15:47:19 2016 +0900
makefiles: Reduce the maximum page size for modules that have a base address.
It avoid bumping into the next allocated base address on 64-bit.
Signed-off-by: Alexandre Julliard [email protected]
On Sat, 14 Nov 2020, Damjan Jovanovic wrote:
winegcc passes that flag already, so the patch should make no difference.
And has done so since wine-1.9.7:
commit e59395208d527d1bffb2725efc85fb798aee7610 Author: Alexandre Julliard [email protected] Date: Mon Mar 28 15:47:19 2016 +0900
makefiles: Reduce the maximum page size for modules that have a baseaddress.
It avoid bumping into the next allocated base address on 64-bit.
Thanks, Alexandre and Damjan! I removed that patch from the FreeBSD ports (and package) of Wine.
Gerald
-
Alexandre Julliard -
Damjan Jovanovic -
Gerald Pfeifer -
Marvin -
Stefan Dösinger