On 18.04.22 12:33, Alex Henrie wrote:
On Thu, Apr 14, 2022 at 9:26 AM Eric Pouech eric.pouech@orange.fr wrote:
I tried to write down what I grasped for the current modules' evolution
since there's always questions floating around this subject, might be worthwhile to document it a bit
Thank you very much for the documentation! Please be sure to put it on the wiki.
Currently, the 32 <> 64 bit is still duplicated:
+-----------------+ +------------------------+ +--------------------+ | FOOBAR.dll (PE) | | FOOBAR.so (ELF 64 bit) | -------------> | ntdll.so (64 bit) | | 64 bit | --------> | (unixlib 64 bit) | ELF dyn link +--------------------+ | | | | -------------> | helper.so (64 bit) | +-----------------+ +------------------------+ +--------------------+
+-----------------+ +------------------------+ +--------------------+ | FOOBAR.dll (PE) | | FOOBAR.so (ELF 32 bit) | -------------> | ntdll.so (32 bit) | | 32 bit | --------> | (unixlib 32 bit) | ELF dyn link +--------------------+ | | | | -------------> | helper.so (32 bit) | +-----------------+ +------------------------+ +--------------------+
When all modules are converted to the new scheme, this shall look like:
+-----------------+ +------------------------+ +--------------------+ | FOOBAR.dll (PE) | | FOOBAR.so (ELF 64 bit) | -------------> | ntdll.so (64 bit) | | 64 bit | --------> | (unixlib ) | ELF dyn link +--------------------+ | | +----> | (64 + 32 bit) | -------------> | helper.so (64 bit) | +-----------------+ | +------------------------+ +--------------------+ | +-----------------+ | | FOOBAR.dll (PE) | | | 32 bit | ---+ | | +-----------------+
This will require that FOOBAR.so correctly handles the "syscall" for both 32 bit and 64 bit unixlib calls. When this is in place, no support for 32-bit .so files will be necessary (both the packages that provide the .so files, but also for the development packages.
This part is still confusing to me. Do any DLLs currently use the new scheme? How can I know which of the two schemes a DLL uses?
Right now in upstream wine, this codepath is locked behind some gates, meaning that all DLLs use the former system, but some DLLs have already implemented support to prepare for when the path is unlocked.
To see whether a DLL supports the wow64 path already, check if it defines "__wine_unix_call_wow64_funcs" somewhere in its source:
https://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=grep&...
-Alex