Re: [PATCH] ntdll: set user_shared_data to 0x7fffffff0000 and virtual_alloc_first_teb can run succeeded on android aarch64

[Stefan Dösinger]

I'm taking the liberty of CC'ing wine-devel in my reply...
> Am 11.01.2022 um 04:38 schrieb [e-mail]:
>
> __ANDROID__ only defined when CC use NDK with flag  "-b aarch64-linux-android".  if flag is "-b aarch64-windows" it would not defined.
>
> 在2022-01-11 02:30:57,Stefan Dösinger写道：
> > > Am 10.01.2022 um 15:22 schrieb [e-mail]:
> > >
> > > The commit only has effect on android-aarch64, because condition macro "if defined(__aarch64__) && defined(__ANDROID__)", it does not affect other platform. Android only has 3-level page table, page size is 4096. pointer(address) size is 8, so every page contain 4096 / 8 = 512 address. it use lg(512) = 9 bits. page use lg(4096) = 12 bits. so 3-level address has valid bits count is 9 * 3 + 12 = 39bits. it can present max address is (2 << 39) - 1 = 0x7fffffffff. user_shared_data must alloc at 0x20000 to end of address. so it is 0x7ffffe0000. 0x7ffe0000 is incorect because it is at middle of address space. and the address space usually be used.
> >
> > Did you deliberately omit the wine-devel CC?

Regardless of where the user address space ends on Android, the user_shared_data struct needs to be in the same place as it is on Windows. Observe that it is in the same place in 32 and 64 bit Windows, and it doesn't care if you run 32 bit Windows with a 2/2 or 3/1 memsplit. The only reason to use it on aarch64 Wine is if aarch64 Windows also places it elsewhere.

If something else is mapped at this place already that's a problem with the wine preloader. The preloader is trying to reserve certain addresses as early as possible, before unix libraries get loaded and place data. The user shared data address is a critical one that's at a hardcoded place. Another example would be 0x400000 and 0x140000000, the default load addresses of x86 and x86_64 .exe files (which usually aren't PIC and have no reloc symbols).

(Semi-educated guess on my end: I guess the process where ntdll finds the area occupied is explorer.exe, which is spawned through java, so a lot of stuff is already in place. That'll be tricky to solve, because we don't really have a preloader...)