I think I solved bug 49208 [1] (failure to create any process on empty Wine prefix under build-dependant circumstances) but I am a bit unsure on the proper fix. The failure is triggered when kernelbase.dll size exceeds 0x410000. If that happens, it does not fit in 0x7b000000 - 0x0x7b410000 range (where 0x7b410000 is kernel32.dll.so load address), and goes in the lower address space, so a bit later an .exe without relocations cannot be mapped to 0x40000. The issue is fixed by 'strip kernelbase.dll' for me. Fitting kernelbase.dll into 0x410000 seems correct to me, but I am not sure about the best way to guarantee that. 1. https://bugs.winehq.org/show_bug.cgi?id=49208
Am 25.05.2020 um 20:09 schrieb Paul Gofman <pgofman(a)codeweavers.com>:
goes in the lower address space, so a bit later an .exe without relocations cannot be mapped to 0x40000.
It's been a while since I understood the library load code well enough (if I ever understood it), but shouldn't we map the .exe file before we map kernelbase.dll? How does ntdll figure out kernelbase is needed without looking into the .exe import section?
On 5/25/20 21:32, Stefan Dösinger wrote:
Am 25.05.2020 um 20:09 schrieb Paul Gofman <pgofman(a)codeweavers.com <mailto:pgofman(a)codeweavers.com>>:
goes in the lower address space, so a bit later an .exe without relocations cannot be mapped to 0x40000.
It's been a while since I understood the library load code well enough (if I ever understood it), but shouldn't we map the .exe file before we map kernelbase.dll? How does ntdll figure out kernelbase is needed without looking into the .exe import section?
I think we want kernelbase and kernel32 at their fixed addresses regardless, some DRMs or just too much inventive applications may depend on that.
On 5/25/20 1:39 PM, Paul Gofman wrote:
On 5/25/20 21:32, Stefan Dösinger wrote:
Am 25.05.2020 um 20:09 schrieb Paul Gofman <pgofman(a)codeweavers.com <mailto:pgofman(a)codeweavers.com>>:
goes in the lower address space, so a bit later an .exe without relocations cannot be mapped to 0x40000.
It's been a while since I understood the library load code well enough (if I ever understood it), but shouldn't we map the .exe file before we map kernelbase.dll? How does ntdll figure out kernelbase is needed without looking into the .exe import section?
I think we want kernelbase and kernel32 at their fixed addresses regardless, some DRMs or just too much inventive applications may depend on that.
I don't think the addresses are based on Windows addresses, though, but rather seem to be specifically to accommodate this kind of bug. See 8f567028123c and 8f7d88c707b8, the latter of which is linked to bug 48417. In particular I think comment 5 of that bug is relevant here.
On 5/25/20 21:59, Zebediah Figura wrote:
I don't think the addresses are based on Windows addresses, though, but rather seem to be specifically to accommodate this kind of bug. See 8f567028123c and 8f7d88c707b8, the latter of which is linked to bug 48417. In particular I think comment 5 of that bug is relevant here.
But do we need those debug sections which get stripped by 'strip' loaded every time?
On 5/25/20 2:36 PM, Paul Gofman wrote:
On 5/25/20 21:59, Zebediah Figura wrote:
I don't think the addresses are based on Windows addresses, though, but rather seem to be specifically to accommodate this kind of bug. See 8f567028123c and 8f7d88c707b8, the latter of which is linked to bug 48417. In particular I think comment 5 of that bug is relevant here.
But do we need those debug sections which get stripped by 'strip' loaded every time?
I don't immediately have enough knowledge to answer that, but I didn't mean to imply that we do.
On 5/25/20 22:59, Zebediah Figura wrote:
I don't immediately have enough knowledge to answer that, but I didn't mean to imply that we do.
So I thought getting rid of debug sections loaded might be beneficial, they are much bigger than all the other parts of executables. I am not sure if the loader should care about that or rather builds can be made with separate debug info?
On 5/25/20 21:59, Zebediah Figura wrote:
On 5/25/20 1:39 PM, Paul Gofman wrote:
I don't think the addresses are based on Windows addresses, though, but rather seem to be specifically to accommodate this kind of bug. Yes, indeed, the address on Windows is different. But should not at least ntdll and kernel32 still have the same address between all the processes on Windows?
FWIW I recently encountered this and bisected it to: e36a9c459d7d1644f401eb49f3684c6fe42f7948 is the first bad commit commit e36a9c459d7d1644f401eb49f3684c6fe42f7948 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue May 5 11:54:11 2020 +0200 kernel32: Move volume functions to kernelbase. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> dlls/kernel32/kernel32.spec | 40 +- dlls/kernel32/volume.c | 1675 +----------------------------------- dlls/kernelbase/Makefile.in | 3 +- dlls/kernelbase/kernelbase.spec | 40 +- dlls/kernelbase/volume.c | 1777 +++++++++++++++++++++++++++++++++++++++ 5 files changed, 1851 insertions(+), 1684 deletions(-) -- -Austin GPG: 267B CC1F 053F 0749 (expires 2021/02/18)
On 5/26/20 12:41, Austin English wrote:
FWIW I recently encountered this and bisected it to: e36a9c459d7d1644f401eb49f3684c6fe42f7948 is the first bad commit commit e36a9c459d7d1644f401eb49f3684c6fe42f7948 Author: Alexandre Julliard <julliard(a)winehq.org <mailto:julliard(a)winehq.org>> Date: Tue May 5 11:54:11 2020 +0200
kernel32: Move volume functions to kernelbase.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org <mailto:julliard(a)winehq.org>>
dlls/kernel32/kernel32.spec | 40 +- dlls/kernel32/volume.c | 1675 +----------------------------------- dlls/kernelbase/Makefile.in | 3 +- dlls/kernelbase/kernelbase.spec | 40 +- dlls/kernelbase/volume.c | 1777 +++++++++++++++++++++++++++++++++++++++ 5 files changed, 1851 insertions(+), 1684 deletions(-) -- -Austin GPG: 267B CC1F 053F 0749 (expires 2021/02/18)
Yeah, it is pretty much possible, those function added to kernelbase could be the last bit after which the size exceeded the threshold on your build. I thought of fixing the problem by removing a dozen of random functions from kernelbase, but I did not test this solution yet.
participants (4)
-
Austin English -
Paul Gofman -
Stefan Dösinger -
Zebediah Figura